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I. INTRODUCTION 



The design and construction of software for a modern 
information system is a rigorous process which can be 
described in a life cycle which consists of the following 
steps : 

1. Feasibility - Defining the basic approach and general 
scope of a software project, with particular emphasis 
on determining the practicality of such a project 
over its entire life span. 

2. Requirements - Specifying the required functions, 
interfaces and actual performance of the software 
system, including operational constraints. 

3. Design - Defining data flow, algorithms, data repre- 
sentations and control structures. Identifying and 
specifying modules. Usually entails at least two 
iterations of refinement. 

4. Coding - Translating the design into a programming 
language. Includes testing of individual components. 

5. Integration - Individual system components are inte- 
grated into the final system configuration. 

6. Implementation - Installation of the software product 
with the host hardware system, to include testing. 

7. Maintenance - All subsequent alterations, modifica- 
tions and improvements made to the complete system. 

This work is an attempt to define a logical software 
design, based on general system requirements, which can be 
’'fine-tuned” by rigorous specification and ultimately used 
as the foundation for the physical implementation of a deci- 
sion support system (DSS) . As such, it does not strictly 
follow the prescribed conventional software development 
process. It is, rather, a hybrid approach at addressing 
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several of the traditional phases of the life cycle: feasi- 

bility, requirements and (logical) design. It is purposely 
of such a general nature in order to facilitate specific 
system requirements and ultimate performance of the entire 
software development life cycle. 

One of the underlying design principles upon which this 
effort is based is that of software generality. An auto- 
mated system to forecast telecommunica tions technology, 
prices and costs should be designed in such a manner as to 
allow for maximum utility within the proposed scope of 
application. This particular DSS logical design enables the 
NCS manager to model a wide variety of technology, price and 
cost situations without the associated overhead imposed by 
multiple application-specific systems. 

The Manager of the National Communications System (NCS) 
has been tasked by the National Security Telecommunica tions 
Policy of 3 August 1983 with implementing this policy under 
the direction and with the consultation of the Policy 
Steering Group. As part of this task, the Manager must: 

1. Ensure the development, in conjunction with the NCS 
operating agencies, of plans to fulfill the princi- 
ples and objectives stated in this directive, 
including an overall telecommunications architecture 
and timetable. 

2. Develop, for review by the Steering Group, overall 
budget profiles regarding approved initiatives and 
related activities. 

3. Prepare annually, or as otherwise directed, a written 
report to the Steering Group on the progress of 
approved initiatives, including an assessment of the 
resources that will be required to attain the objec- 
tives of this directive £Ref. 1]. 

For a manager to make effective decisions and to prepare 
effective and timely plans, a certain amount and quality of 
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information has to be available. Martino [Ref. 2] states, 
"One of the best-kept secrets of the planning profession is 
that planning has nothing to do with actions to be taken in 
the future. Instead, planning deals with actions to be 
taken in the present." 

The information required for planning into the future 
partly consists of estimates as to what the future holds. 
The NCS must have estimates of what technologies will be 
available at a later time and what the cost and price of 
that technology will be. A decision support system system 
which utilizes forecasting techniques and models can be used 
to derive accurate estimates and aid NCS managers in making 
decisions based upon these estimates. Forecasts of tech- 
nology are useful because a technological change can: 

1. Provide new methods of achieving objectives. 

2. Render certain means of achieving objectives obso- 
lete. 

3. Render certain objectives obsolete. 

The necessity to track technology growth is particularly 
important once it has been identified as a needed tech- 
nology. Isenson [Ref. 3] found through his investigations of 
Project Hindsight that a real need results in accelerated 
techn clogical growth. The greater the rate of the growth of 
a technology, the more it can influence previously made 
plans . 

This paper will develop a decision support system to 
forecast technology, prices, and costs for use by the 
National Communications System. The next chapter is an 
overview of the NCS. Chapter III introduces the concept of 
forecasting and forecasting models, with a discussion on how 
they may effectively be utilized by a government agency such 
as the NCS. The actual logical design for the decision 
support system will then be developed and the methods 
utilized in its design are discussed. The conclusions will 
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II. THE NATIONAL COMMUNICATIONS SYSTEM 



A. OVERVIEW 

The National Communications System was formed cr. 21 
August 1963 as a result of a recommendation by the National 
Security Council that the Executive Office move to identify 
and coordinate the communications needs of the Federal 
Government. Originally envisioned as a means to integrate 
the many systems found throughout the government, the 
general mission of the NCS continues to be to ensure the 
surviveability of communications during and subsequent to 
any national emergency. In order to accomplish this mission 
the NCS is organized not as a homogenous, separate entity; 
rather, it is an arrangement of heterogeneous telecommunica- 
tions systems which are provided by their sponsor Federal 
agencies. In its early years of existence the NCS was 
comprised mostly of General Services Administration (GSA) 
and Department of Defense (DOD) assets. Today, however, 
virtually every major Federal agency is a participating 
member of the NCS. 

The physical components of Federal telecommunications 
systems and networks included under the NCS may be described 
as the following: 

1. Automatic telephone route control switching facili- 
ties and associated first level user switching facil- 
ities. 

2. Telephone and digital data switching facilities and 
primary common user communications centers. 

Special purpose local delivery message switching and 
exchange facilities. 
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4. Fixed route government owned or leased transmission 
facilities under exclusive control of a government 
agency. 

5. Government owned or leased radio systems. 

6. Technical control facilities which are under exclu- 
sive control of a government agency. 

7. Other services provided by a common or specialized 
carrier on a continuing basis, via commercial facili- 
ties not designated for exclusive government use. 
These services, like exclusive use services, will 
still be assigned an appropriate restoration priority 
in the event cf national emergency or other disrup- 
tion of the service. [Eef. 4] 

Most NCS operating component systems are long-haul, 
trunk, point-to-point systems. They are planned, operated 
and funded by their sponsor agencies to fulfill a specific 
peacetime need. The current NCS management doctrine is to 
provide joint central planning, standardization and program- 
ming. The long range goal is to ensure progressive, system- 
atic improvements existing systems in order to allow 
efficient and effective transition from peacetime to emer- 
gency conditions. 

B. NCS POLICY 

As the number of NCS operating components has grown over 
the years, so also have the organizational responsibilities 
and system complexities. In order to clarify and define the 
NCS goals and objectives, the National Security Council 
(NSC) established in 1979 the National Security 
Telecommunications Policy. This policy directed the NCS to 
ensure telecommunications assets provide for: 

1. Emergency communications between the National Command 
Authority and appropriate forces to support retalia- 
tory action in the event of enemy nuclear attack. 
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Military operational communications for both general 
and nuclear conflicts. 

3. Communications in support of military mobilization. 

4. Communications to ensure government continuity in the 
event of nuclear or natural disaster, and recovery 
from the same. [Ref. 5] 

In August 1983 the national telecommunications policy 
was further defined. The new policy addresses the vulner- 

ability of existing NCS systems to nuclear attack and 
directs enhancements and improvements (i.e., switches and 
control centers) be physically located away from likely 
nuclear target areas and, whenever feasible, existing system 
components be hardened. [Ref. 1] 

Actual policy guidance for the NCS in the areas of tele- 
communications planning and development is fragmented and 
originates from multiple sources at the Executive Office 
level. For example, the Office of Science and Technology 
Policy (CSTP) is tasked with the responsibility for the 
collection, recording and evaluation of existing telecommu- 
nications facilities and the development of profile informa- 
tion detailing the residual capabilities of these systems 
and networks under various extraordinary conditions, 
including nuclear and other national emergencies [Ref. 6]« 
Such information is used by the NCS in the conduct of resto- 
ration and allocation activities, resources evaluation, 
damage assessment, requirements evaluation, and priority 
determination. The OSTP facilities status evaluation 
provides the NCS raw data pertaining to system gross opera- 
tional capabilities in terms of (1) link/trunk capability, 
(2) call demand/acceptance capability of voice switching 
systems, (3) message processing capability of record traffic 
switching systems, (4) user/subscriber access capability of 
voice and record switching systems, and (5) residual major 
system access concentraters. This data can and should be 
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utilized by the NCS to ensure Federal telecommunications 
systems, derived from common carrier networks, are intercon- 
nected and capable of interoperation to the maximum extent 
possible. 

C. PEOCUREHEHT OF SERVICES 

More than 95% of the communication services utilized by 
the Federal government and its agencies within the conti- 
nental United States are provided by common user systems 
leased from and operated by the major common and specialized 
commercial carriers (the vast majority are leased from AT&T 
Long Lines and associated Bell operating or interconnect 
companies) [Ref. 7 ]. "Common" user systems means that the 
physical facilities from which the government services are 
derived are usually also common to public message services 
with provisions made to segregate the two services. Close 
and continual coordination between the NCS and the private 
sector telecommunications industry is facilitated by the 
Federal Communications Commission (FCC) and the National 
Industry Advisory Committee (NIAC) . During wartime or other 
national emergency the authority to requisition and contract 
for supplies and equipment, and to restore, expand, repair 
and construct telecommunications systems is delegated to the 
FCC. However, the NCS retains overall responsibility for 
integrating all government communications. In order to 
perform its emergency functions, the FCC relies heavily upon 
the NCS Telecommunications Emergency Management System 
(NTEMS) . 

Peacetime procurement responsibility is centralized 
also, but divided between GSA for civil agencies and the 
Defense Ccmmunica ticns Agency (DCA) for DOD systems. 
Certain civil agencies and components have been authorized 
independent authority to procure directly from common and 
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III. USE OF FORECASTING MODELS IN GOVERNMENT 



A. CONCEPTS 

The general concept of cost and price projection is an 
integral issue associated with the acquisition of major 
systems, commercial products and industrial services by 
agencies of the federal government. This concept normally 
is addressed during the rigorous process known as economic 
analysis, the outcome of which is a major factor either in 
the selection of a choice between two or more alternatives, 
or in assessing the economic consequences of a choice 
already made between alternatives. Unfortunately, the 
literature pertaining to economic analysis includes rather 
generalized and imprecise guidance for the conduct of cost/ 
price estimation, key elements of the process. In practice, 
costing and pricing within the federal government varies 
widely from agency to agency, an£ even within agencies there 
may be variety, dependent upon the type of product or 
service being acquired [Ref. 8]. The use of technology, 
price and cost forecasting models is one method available to 
complement and enhance an agency’s established employment of 
economic analysis and estimation in the acquisition life 
cycle . 

Regardless of the scope of the project or program 
involved, the acquisition process can be viewed as a logical 
progression of iterative reviews, determinations and evalua- 
tions to reconcile periodic adjustments to program objec- 
tives and requirements or resource availability. This 
process overlaps the traditional functions of planning, 
budgeting, contracting and contract administration, each of 
which can be examined as an area of specialization. 
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Historically, federal departments and agencies have utxlized 
separate estimation and analysis units within each stage of 
the acquisition process. In addition, each unit has tended 
to utilize a unique costing and pricing technique for each 
of the functional specialties. Furthermore, as each esti- 
mate and analysis is forwarded through the organizational 
hierarchy, policy reviews and revisions take place. 
Although some agencies utilize a centralized cost/price 
estimation and analysis activity, they are the exception to 
the rule. The normal process entails redundancy of effort 
and, all to often, results in poor cost and price informa- 
tion. Certainly it is given that the adequacy of data is a 
major factor in the quality of cost and price estimates and 
analyses, but the importance of the overall methodology 
utilized must not be discounted. This is the case particu- 
larly for estimates and analyses involving new technology 
and major systems. 

The traditional acquisition costing/pricing process can 
be significantly enhanced by use of forecasting techniques 
and methods. Forecasting is a process whose objective is to 
predict future events or conditions under an assumed set of 
circumstances. The most common applications of forecasting 
involve the use of estimating models to predict quantitative 
values of certain variables outside the sample of data actu- 
ally observed. In the case of cost and price forecasts, 
these values would most likely assume a probability distri- 
bution rather than a point forecast. Technology forecasting 
looks more toward the time period by which certain parame- 
ters of a given technology will be achieved. An example of 
this would be to forecast the year in which 90% of telecom- 
munications common carriers will be using digital voice 
circuits rather than analog circuits. 

The forecasting process, like the product or service for 
which the forecast is made, can be described in terms of a 
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life cycle. The forecaster begins the process by identi- 
fying facts and other data about past trends and previous 
forecasts relating to the problem under consideration. 
Particular attention is given to determining the cause of 
variances between previous forecasts and actual system 
behavior. The forecaster must next determine and organize 
future parameters of the decision problem. A suitable model 
which describes the problem space is then constructed, along 
with a method and measure of accuracy and reliability. 
During the course of the project, periodic samples are taken 
to compare the forecast with actual behavior, documenting 
variances as they occur. Finally, the forecast is revised 
as necessary. [Ref. 2] 

A forecast is only as accurate as its model, and a model 
is only as accurate as its data sources. Moreover, the 
model used represents a compromise between reality and 
manageability. It must identify essential factors while 
disregarding non-critical ones. A good model specifies 
interrelationships among parts of the system such that it is 
reasonably detailed and explicit to ensure the model 
adequately describes the real-world system. However, it 
must also specify them in such a way that it is understand- 
able so that proper analysis and conclusions regarding the 
real-world system can be made. 

B. PRICE/COST FORECASTING MODELS 

This work is not an attempt to survey the entire field 
of available forecasting models. The focus will be on the 
most common type of parametric model, the algebraic model, 
which is particularly well suited to the NCS application 
because of the ease with which it may be expanded and modi- 
fied. The algebraic model typically consists of several 
equations, each with a separate meaning and role. The model 
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determines values of certain endogenous variables, the 
jointly dependent variables which are simultaneously solved 
by the relations of the model. Independent exogenous vari- 
ables are determined outside the system but influence it by 
affecting the values of the endogenous variables. They 
affect the system but are not in turn affected by it. An 
econometric model is an algebraic model that typically 
includes one or more random variables (disturbance terms) 
and represents a system by a set of stochastic relations 
among the variables of the system. Such a model generally 
specifies the probability distribution of each endogenous 
variable, given the values taken by all exogenous variables 
and given the values of all parameters of the model. 
[Ref. 9] 

A cost model is used to predict the anticipated costs 
likely to be incurred in a project. Like other models, when 
a cost model equation or system of equations is derived from 
statistical analysis of a sample of past projects, an asso- 
ciated factor is a degree of imprecision or uncertainty. 
The validity of the model is a function of how widely the 
data are scattered around the prediction line or curve. 
Cost models must generally be individually structured to 
best meet the purpose for which they are intended (Table 1) . 
If the forecast is meant to aid in the choice between alter- 
natives, the differential life cycle cost model would be 
used. Such a model would compare the differential costs 
associated with the alternative systems. Detailed compar- 
ison between the alternatives would be provided by summing 
the differential costs identified with the applicable cost 
elements chosen. Conversely, a cost model based upcn total 
life cycle cost would concentrate on applicable cost 
elements over the projected life expectancy of a particular 
equipment or system. The model builder would identify the 
cost categories and associated cost elements to be utilized 
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TABLE 1 

Life Cycle Cost Models 
Tot al L ife Cyc le Cost Mode l 

Associates all applicable cost elements over the life- 
time cf a system. 

Different ial Life Cy cle Cost Mo d el 

Compares differential costs between two similar cost 
elements of two different systems. 



as model parameters. Table 2 is an explanation of the 
conventional major cost categories. 

C. TECHNOLOGY FORECASTING MODELS 

Technology forecasting models are similar to price/cost 
models in that the primary determinant of the quality of the 
forecast is in the variables which are brought into the 
model and how they are weighted in relation to one another. 
Once this has been accomplished, different techniques can be 
utilized to fit a curve to the historic data in order to 
project the value of the technology parameter at a future 
time. The model is highly dependent upon the core assump- 
tions made about the environment which is being forecast. 
In particular is the assumption regarding the existence of 
upper limits (or lower limits in the case of time reduc- 
tions) on the capabilities of the technology being modeled. 
An example of an upper limit assumption would be the speed 
of light for spacecraft velocities. Other than extrapo- 
lating trends into the future by curve fitting, technology 
forecasting can sample the amount of literature circulating 
in an area of technolcgy. By monitoring the growth (or lack 
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TABLE 2 

Major Cost Categories 



and De velopment Co sts 

All costs associated with the research, development, 
test and evaluation of the eguipment/system. Normally 
these costs are incurred during concept initiation, 
validation and full scale development. 



Nonrecurring, Investment Costs 

All costs incurred one time beyond the program devel- 
opment phase and during the program production phase. 
These costs can occur if there is a change in design, 
contractor or manufacturing process. 



Rec urr ing Investment Cost s 

All production costs that recur with each unit 
procuced. 



Oper ating and Maintenance Costs 

All costs associated with personnel, material, facili- 
ties and other costs required to operate, maintain and 
support an eguipment/system during its useful life- 
time. 



of growth) in an area, it can be estimated that the 
increased communications among researchers will result in an 
exponential growth of knowledge, likely to result in a 
breakthrough or an advancement of the technology being 
studied. This area of forecasting can be directly influ- 
enced by infusion of government resources into research 
[Ref. 3], If a certain level of a parameter of a technology 
is desired by a certain date, the amount of research and 
development necessary now can be estimated. The recent 
Presidential initiative regarding the so-called "Star Wars" 
technology is an example of this technique. 
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Although forecasting models are well suited for adapta- 
tion to automated systems, they are not without their poten- 
tial problems. Depending upon the real-world project and 
model application, forecasters may find a limited number of 
relevant statistical procedures available. Once 
constructed, models may quickly become obsolete by the rapid 
growth of the technology being forecast. Hence, effort must 
be directed toward a method for adapting the model for tech- 
nological advance even during periods of rapid growth. The 
forecaster may be confronted with the mathematical problem 
of solving k equations in n unknowns (k < n) . A host of 
problems involving accuracy of the model may be caused by 
omission of a relevant exogenous variable, disregarding a 
qualitative change in one of the variables, inclusion of an 
irrelevant variable, incorrect definition of a variable, and 
in the case of econometric models, incorrect specification 
of the manner in which the stochastic disturbance term 
enters the equation. 

The effects of divestiture and deregulation of the tele- 
communications industry are major contributing reasons for 
the National Communications System to consider use of fore- 
casting techniques. As the NCS continues to grow in size, 
scope and complexity cf participating systems (for example, 
the conversion from analog to digital voice circuits), even 
more powerful tools will be required to exert effective 
managerial control over further development. Accordingly, 
the objective of forecasting technology, cost and price is 
not to provide a managerial decision, but to derive further 
inputs to the managerial decision-making process. Numerous 
potential applications exist within the traditional 
Planning, Programming and Budgeting System (PPBS) and acqui- 
sition cycles. For example, it can be used in lieu of 
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conventional cost-estimating during the cost/benefit anal- 
ysis (concept develo fluent of the acquisition cycle) . It can 
be used to evaluate alternatives during strategic planning. 
It can be utilized during periodic revisions of the 
Five-Year Defense Plan (FYDP) , or similar intermediate-term 
plan for GSA-procured systems. As a general rule, an auto- 
mated forecasting system would be ideal for use whenever 
traditional economic/technological analysis is too elabo- 
rate, too time-consuming and/or too expensive for the scope 
of the particular problem or project at hand. 
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IV. PRELIMINARY DATA DICTIONARY DESIGN 



In order to develop a database for a decision support 
system it is necessary to look at the overall requirements 
for designing such a system with special emphasis on the 
data which will be utilized. The DSS architecture presented 
by Dolk [Ref. 10] consists of four major components: (1) 
dialog, (2) model base, (3) knowledge base, and (4) data- 
base. The dialog is the primary driver of the system. It 
is the interface with the user; therefore, the dialog is 
dependent upon what outputs the decision-maker wants from 
the DSS and what inputs can be to provided to get that 
output. The model base will provide the basic algorithms of 
the system models as well as the value abstractions of the 
coefficients for the variables to be utilized by the model 
algorithms. The knowledge base contains a set of heuristics 
which determine what type model or combination of models 
will be processed fcr a given circumstance provided by the 
user. The database will contain the structure and values of 
all data in the DSS which is subject to modification and/or 
addition by the user without modifying the program itself. 
The data utilized by the dialog, model base, and knowledge 
base determine what will be in the database, and will there- 
fore be examined briefly in turn. 

A. DIALOG 

The "rule of thumb" in DSS design (or in any systems 
analysis for that matter) is to first determine what will be 
the outputs and inputs to the system. Because all interface 
with the user is through the dialog, this is paramount to 
determining what the dialog is to be. The prime question to 
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be asked is, "What does the user need in a forecast of tech- 
nology?" The answer to that guestion for the purposes of 
this DSS is that the decision-maker wants the DSS to provide 
a presentation of trends for a given parameter in an area of 
a technology, given a set of assumptions and optionally 
given a set of parameters from other areas which may impact 
upon the technology, including the degree to which they do 
so. 

The following are outputs required from the dialog: 

1. A list of the assumptions used in generating the 

forecast . 

2. The type of model (s) being utilized. 

3. A graphical presentation of historical data versus 
time extrapolated by one of the models to get an 
indication of a trend, whether increasing, decreasing 
or steady and which includes the scale used, whether 
linear or logarithmic. 

4. The source of the data on the graph and its type, 
whether subjective, objective or estimate. 

5. A comparison of this forecast with previous fore- 

c asts. 

6. Which parameters of the model are exogenous or 

endogenous and of these, which can be influenced by 
the decision-maker. 

The following inputs to the dialog are required: 

1 . An ability to create data with these characteristics: 
identifiers for name, type of factor it is, source of 
the data, date of the data entry and date of the data 
observation . 

2. An ability to alter assumptions and parameters in 

order to observe any changes in the output. This can 
include a means for indicating the stochastic nature 
of some of the variables. For example, in a price/ 
cost model the expected future interest rates of 
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treasury bonds may be estimated as a triangular 
distribution cf the interest rate around a most 
likely value for the interest rate, bounded by an 
estimated high value and low value which can then be 
iterated through the model as a Monte Carlo simula- 
tion. 

3. An ability to create different model equations for 
input into the model algorithm. 

4. An ability to override the knowledge base and select 
a specific model to run. 

B. MODEL BASE 

This DSS utilizes two primary models. The first of these 
is a curve fitting model which regresses a straight lire on 
the plots of five different functions of the factor or 
aggregate model score to forecast. These functions are a 
Pearl growth function, a Gompertz growth function, a func- 
tion in which the natural logarithm of the dependent vari- 
able is taken, and a function in which the natural logarithm 
of the dependent variable and the natural logarithm of the 
independent variable are calculated. The regression which 
has the highest correlation factor is selected for use in 
extrapolating into the future. This method of forecasting 
has been selected due to its simplicity and intuitive under- 
standing of the process by a manager. The second model in 
the DSS is a simple cross impact analysis model developed by 
Julius Kane [Bef. 2], 

1 • S co ring Mod el 

A scoring model will take different factors named by 
the decision-maker and combine them to determine an aggre- 
gate score (hence the name scoring model) . This is accom- 
plished through queries directed at the user to determine 



28 



the relationships among the factors. Any factors which are 
essentially the same are eliminated so that only one factor 
will represent that area in the model. Next the factors are 
grouped to determine whether they are additive or multipli- 
cative, either of the entire model, or of groups, and so on. 
Care must be taken in choice of multiplicative factors, for 
if the value of the factor is zero, then all of the factors 
which it multiplies are then zero. Weights are now assigned 
by the user to the different groups or individual factors. 
Desirable and undesirable factors and groups are separated 
with the desired factors being in the numerator and unfavo- 
rable factors being placed in the denominator. This is the 
basic model equation and can be stored as such. 

The user must identify whether the data is subjec- 
tive or objective. If subjective, the user will utilize a 
standard scale of zero to nine in selecting the value for 
the factor, while objective data will be examined and the 
mean and standard deviation for each factor's data being 
calculated. The mean of the data can then be assigned a 
value of the user's choice, and the other values determined 
as fractions of the standard deviation to range from a low 
to a high value also of the decision-maker's choice. 

This type of model is useful in comparing different 
technologies which perform similar missions. An example 
drawn from telecommunications technology is a comparison of 
satellite communications versus landlines versus microwave 
links. For determining the relative vulnerability of each 
to disaster or nuclear attack, a subjective factor can be 
utilized, while cost of maintenance or installation will be 
an objective factor. 

2 • Eearl and Go m pert z Curv es 

These two curves are discussed jointly because they 
are essentially the same functions, differing mainly in the 
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underlying assumptions. Both curves are "S" shaped and are 
extrapolated by first straightening out the curve as plotted 
by the factor data. This is accomplished by taking the 

logarithm of the curve, once for the Pearl curve, twice for 
the Gompertz curve. The data thus transformed has a 

straight line regressed on it to obtain the values for the 
curve functions. The equation 1 for the Pearl curve 
(Equation 4.1) and its algebraic transformation (Equation 

4.2) utilize In a as the constant and b as the slope, b 
taken to be positive. L is the assumed limitation of the 
technology and t is time while y is the value of the factor 

y = L/(1 + a * (e ** (-b * t) ) ) (4.1) 

Y = (L - y)/y = In a - b * t (4.2) 

under consideration. The Gompertz curve equation (Equation 

4.3) and its algebraic transformation (Equation 4.4) utilize 
In b as the constant and k as the slope. The other two 

y = I * (e ** (-b * (e ** (-k * t) ) ) ) (4.3) 

Y = In (In (L/y) ) = In b - (k * t) (4.4) 

variables are the sane as before. 

The different assumptions underlying the choice of 
these twc curves is in the dynamics of the technology being 
forecast. If the previous progress in implementation or 
development of a technology will influence the rate of the 
progress of the technology, then a Pearl curve should be 



l The following translations describe notations which may 
be unfamiliar to the reader: 

1 ** = multiplication operator 

»**» = exponentiation operator 
'In’ = natural logarithm function 
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used. However if the determining factor is how much remains 
to be accomplished before the assumed limit to growth of the 
technology is reached, then the Gompertz curve should be 
utilized. 

An example of the use of the Pearl curve is a fore- 
cast of the number cf households which have access to a 
broadband communicaticns media. The factor in this instance 
is the number of homes with cable television installed. The 
maximum limit {’!’) is that 100% of households which have 
televisions have cable installations. A Pearl curve is 
appropriate because the technology is driven by the degree 
of acceptance with which it is received by the public. 

A forecast of the percentage of common carrier local 
distribution systems which will have optical fiber as the 
transmission media can be modeled by a Gompertz curve. The 
limit in this example is for 100% of existing local distri- 
bution systems to have been replaced by optical fiber 
systems. Since this substitution is influenced more by the 
number of systems remaining to be upgraded rather than by 
the number of systems which have already been implemented, a 
Gompertz curve is the correct growth curve for the forecast. 

3 . Cross Impact An alys is 

This is a simple model which takes a factor in an 
area cf a technology and determines the next value it will 
have as a result of the impact of other factors, both exoge- 
nous and endogenous. The model is simple in that only the 
impact of a single variable upon another variable is deter- 
mined at a time, not all variables at once. The inputs by 
the decision-maker are purely subjective evaluations of what 
the impacts of certain chosen variables are upon the factor 
being evaluated, plus the original value of this factor 
(subjectively scaled from zero to one in increments of 
0.001). The use of such a model is for a decision-maker to 
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get an idea of the results of varying the impacts of other 
factors upon a factor. Therefore, it is necessary for the 
impacting factors to be defined as either endogenous or 
exogenous variables so that the decision-maker will know 
which variables are able to be influenced. An example of an 
application of this model is found in Chapter VI. 

C. KNOWLEDGE BASE 

The knowledge base of this particular DSS does not have 
anything stored in the database. The rules for determining 
which models to run are within the algorithms of the program 
itself. The only impact upon the data dictionary is in the 
identification of objects passed by the dialog to the knowl- 
edge base. This would consist of determining whether a 
request for a model run is for more than one specific area 
of a technology, which would activate a scoring model to 
arrive at a conglomerate representation of the overall tech- 
nology, or in determining whether a Pearl or Gompertz curve 
is to be utilized in extrapolation of the data. The cross 
impact model will he invoked when the user specifically 
directs that it be run. 

E. DEVELOPMENT OF THE DATA DICTIONARY 

The technique to be utilized in the development of this 
DSS is drawn from the works of Yourdon [Ref. 11] and DeMarco 
[Ref. 12]. Their methods of structured analysis and design 
result in a logical flow toward a complete software design 
without the large amounts of paper normally associated with 
a software design project. The less documentation which has 
to be changed in later design revisions of the DSS, the 
greater the possibility that the documentation will be 
updated to reflect changes made to the actual software. The 
essential elements of the DeMarco and Yourdon methods are 
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and the 



the development of a data flow, a data dictionary, 
process descriptions . In order to develop the data flow, 
the composition of the data inputs and outputs to the system 
have to he described in the data dictionary. The data flow 
will only show the flow of the data objects through the 
system, while the process descriptions provide information 
about the content and processing of the data. 

The data objects are described in the data dictionary 
primarily through the use of the three types of relations 
presented by 3ohm and Jacopini [Ref. 13 ]. These are 
seguence, selection and iteration. Sequence is a concatena- 
tion of two or more data objects and/or data elements 
together. Selection is a choice between two or more data 
items. Iteration is the repetition of a data object, or 
group of data objects, zero or more times. In addition to 
these relations, an optional relation is added so that it is 
possible to indicate if a data object may or may not be part 
of a larger data object. For this data dictionary a data 
element is considered to be data which is not further broken 
down into other data elements. The level to which a data 
element is broken down is left to the user and the data 
dictionary designer. A data object may be broken down into 
component data objects and/or data elements. Table 3 
explains the notation utilized in this data dictionary. 

The data dictionary for the DSS is developed by 
analyzing the descriptions of the dialog, model base and 
knowledge base in the previous sections. This will result 
in an initial look at how data objects may flow through the 
system. Because this is the initial version of the data 
dictionary it is inevitable that the data objects will 
change, be added, or be dropped if it appears during further 
design of the system that they will not be utilized by the 
system. Usually a data flow technique is utilized in 
analyzing an existing system in order to automate it. This 
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TABLE 3 

Data Dictionary Notation 



No tat ion 
x = a + b 
x = [ a | b ] 
x = {a} 
x = (a) 
x = y {a} 
x = {a} z 
x = y {a} z 



X Consists Of 

data objects a and b 

either a or b 

zero or more occurances of a 
optional data element a 
y or more occurances of a 
z or fewer occurances of a 
between y and z occurances of a 

S 



design is different in that an attempt is being made to 
design a system which does not yet exist. Therefore the 
data dictionary depicted in Table 4 is admittedly of a 
preliminary nature. 

With the use of this data dictionary an initial data 
flow can be constructed. The data flow will be expanded to 
different levels until the transformation of the input data 
to the output data is fully described. Upon the completion 
of the expansion of the data flow the process descriptions 
will be written. These descriptions will be compared with 
the data dictionary in order to determine if any of the data 
is not utilized or if there is data which must be added to 
the data dictionary. The data is then normalized and a data 
structure diagram is constructed. With the addition of the 
format in which the data will actually be stored, the data 
dictionary will be complete and serve as a reference docu- 
ment during the detailed design of the decision support 
system. 
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TABLE 4 

Preliminary Data Dictionary 






ALGORITHM_N AM E 


= *Name of a modeling algorithm 
used as part of key to 
identify a data object which 
contains the data which will 
be used by a model* 


CHARACTERISTIC 


= [ "Exogenous" | "Endogenous" ] 

♦Identifies whether data is 
controllable* 


DATE 


= "MM/DD/YY" 


DA TE_CF_ ENTRY 


= DATE 

♦Date data entered into 
database* 


DAIE_CBSERV ATION 


= DATE 

♦Date data for ELEMENT ENTRY 
observed or estimated* 


DISTRIBUTION 


= [ "Norm"| "Uni" J "Tri" ] 

♦How stochastic variable 
is distributed* 


ELEMENT 


= *Sub-area within a 
technology* 


E L E M E NT_ ANALYSIS 


= [ "Historical" | " Estimate” ] j 


ELEMENT_ENTRY 


= DATE OF OBSERVATION 
ELEMENT - SOURCE 
DATE OF~ENTRY 
EL E ME N T - V AL U E 
ELEMENT^ANALYSIS 


ELEMENT_SOURCE 


= *Source of data for 
ELEMENT_ ENTRY* 


E1EMENT_ VALUE 


= MOST LIKELY VALUE 
(HIGH VALUE - 
LON VILUE 
DISTRIBUTION) 


FACTOR 


= FACTOR IDENTIFIER 
FACTOR - T YPE 
(UNITSF 

CHARACTERISTIC 
{ELEMENT ENTRY] 
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Table 4 

Preliminary Data Dictionary (cont'd) 



F A CTO R_ ID ENT IFIER 


= TECHNOLOGY 
ELEMENT 


FACTOR_OPERATOR 


= GROUP_OPERATOR 


F AC10R_TYPE 


= [ "Subj"| "Obj" ] 


FACTOR_ WEIGHT 


= *Any positive integer - a 
subjective evaluation of 
the factor in the sub- 
group* 


GRCUP_I DENT IFIER 


= * A unique name within the 

data object to identify 
a grouping* 


GRCUP_LEVEL 


= *An integer greater than 0 
used to indicate which other 
groups this group acts on 
The lower number groups act 
on all groups of higher 
number* 


GRCUP_OPERATOR 


= [ »Mult"| "Add" ] 


GRCUP_WE IGHT 


= *Any real number - a 

subjective valuation of the 
group in the model* 


GROUPS 


= GROUP IDENTIFIER 
GROUP - OPE RATOR 
GROUP - WEIGHT 
GROUP - LEVEL 
[SUB GROUP 
SUB GROUP WEIGHT 
S UB - GROU P — OPERATOR} 


HIGH_VALUE 


= *Any real number greater 
than or equal to the 
ELEMENT VALUE’S 
M0ST_LIKELY_ VALUE* 


IM P AC T_ FACTOR 


= *A subjective value - a 
single digit 0-9* 


I M P A C T I N G_F A C TO R 


= FACTOR_IDENTIFI ER 


LIMITIN G_FACTOR 


= FACTOR IDENTIFIER 
F ACTOR - T YPE 
(UNITS7 

CHARACTERISTIC 


1 

l 


1 [ELEMENT ENTRY} 1 
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Table 4 

Preliminary Data Dictionary (cont'd) 



LC W_V ALUE 
MODEL 



MODEL IDENTIFIER 



MOST_II KELY_V ALU E 
SC ALE_FOR_D AT A 
SUB GROUP 



SUB_GEOUP_IDENTIFIER 
SUB GROUP OPERATOR 



♦Any real number less than or 
equal to the ELEMENT VALUE'S 
MOST_LIKELY_VALUE* ” 

ALGORITHM NAME 
MODEL IDENTIFIER 
{GROUPS} 

-'LIMITING FACTOR} 

[IMPACTING FACTOR 
IM PACT_ FACTOR} 

♦Name given by user used 
along with ALGORITHM_NAME 
to identify the data object 
containing the data to 
be modeled* 

♦Any real number* 

[ "Linear" | "Log" ] 

SUB GROUP IDENTIFIER 
fSUl GROUP 
SUB GROUP HEIGHT 
SUB~GROUP — OPERATOR} 

{FACTOR ” 

FACTOR OPERATOR 
FACTOR~WEIGHT] 

♦A recursive definition 
Sub-groups may contain 
other subgroups* 

♦A unique name for a sub- 
group within the group* 

GROUP OPERATOR 



SUE_GEOUP_WEIGHT = *Any positive integer - a 

subjective evaluation of the 
SUB GROUP in the GROUP or 
SUB-GROUP* 

TECHNOLOGY = *Naire of a technological area 

at user's discretion* 



UNITS 



♦Units of measure for 
ELEMENT ENTRY'S* 
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V. PROCESS SPE CIFICATIONS 



The process specifications are descriptions of each of 
the nodes in the system where data flows are transformed 
from one form of composition into another composition. A 
characteristic of these specifications is that each should 
describe an underlying policy of the system, specifying what 
is to be accomplished rather than how to accomplish it. To 
do this they are written in a form known as Structured 
English. Structured English is a form of English in which 
the majority of nouns used will come from the data 
dictionary. A reserved list of words is utilized to denote 
the actions within the process. Examples of words from this 
list are those words which use the three techniques of 
program construction. For sequence structures statements 
within a program should follow one another. To show decision 
the usual constructs are * If ... then. .. else ' , 'If. ..then', or 
' If .. .t hen. .. otherwise ' . For multiple decisions some varia- 
tion of a 'Case' structure is employed (i.e., Case of This, 
Do This, Do That, Do The Other Thing) . Iterations are 
expressed as ' Repeat ... Until some condition is met’, 'While a 
condition is present do...', or 'For a certain number of 
times do...'. A thorough treatment of the topic is provided 
in [Ref. 12]. 

The process specifications written here are referred to 
as process mini-specifications or ’mini-specs', due to the 
fact that each specification is unique to itself and 
describes a smaller system contained within the whole 
system, each having its specified inputs and outputs. To the 
remainder of the system the process will appear to be a 
'black box' with inputs going in and outputs coming out, 
somehow transformed by the process. In this chapter the 
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inputs and outputs for each process are listed. The under- 
lying policy of each process is provided to indicate what 
the process is to do. Due to the length of the mini-specs, 
they have been placed in a separate appendix. Prior to each 
mini-specification the inputs and outputs along with their 
respective sources and destinations are provided. Following 
the mini-specifications are the McCabe complexity numbers of 
the processes, and a description of the basis paths of the 
processes. 

A. THE MCCABE COMPLEXITY METRIC IN SOFTWARE DESIGN 

The McCabe Cyclomatic Complexity Measure was first 
developed for testing of already coded modules. McCabe’s 
p :>er [Ref. 14] presents the idea of applying a complexity 
mi isure in the design phase of software design. Previously 
this metric had only been applied to completed code. The 
reasoning behind application of this metric in the design 
phase is that many more errors occur in the design phase 
than in the coding phase. This fact is demonstrated by the 



TABLE 5 

Relative Frequency of Design and Coding Errors 





Source Statements 


Design Errors Coding Errors 


Me lif ication 


(No.) 


(%) 


<*) 


A 


1253 


73.6 


26. 4 


E 


9880 


73. 7 


26.3 


C 


779 


35.6 


64.4 


D 


S63 1 


51.6 


48. 4 


E 


4575 


58.8 


4 1.2 


data in Table 


5 which is from a 


software 


reliability study 


conducted at 


TRW of the percent 


of errors 


introduced in a 



series of modifications to a large software project (100,000 
lines of code) [Ref. 15]. The extension of the McCabe 
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complexity metric to the design testing of processes will 
help to identify logic path errors and will provide the 
number of basis paths through a process. A basis path is 
one of the set of possible independent paths from the entry 
point of the process to the exit point from the process. 
The set does not include variations from the independent 
paths due to iterations of statements along the path. 
Knowledge of these paths helps to determine the makeup of 
the test data to be utilized later in testing the coded 
designs. 

The primary purpose of the McCabe Cyclomatic Complexity 
measure (henceforth referred to as "the comp exity measure") 
is to limit the number of independent paths in a process. 
Yourdon and Constantine [Ref. 11 ] present the idea that an 
acceptable guideline for the length of a process is that the 
Structured English syntax or decision table be no more than 
one page in length. They acknowledge that this is a very 
general guideline but that it should be utilized in addition 

to ensuring that a process be strongly cohesive. However, as 

pointed cut by McCabe, a 50 line process with 25 selection 
statements will result in 33.5 million control paths. 

In order to determine what the complexity of a process 
.iould be, it must first be established how complex a 
process may be before a programmer can no longer effectively 
and rapidly understand it. Throughout managerial, psycholog- 
ical, and software engineering literature this complexity 
limit is known as the Hrair limit. As applied to software 
design, it has been determined to be seven logical events, 
plus or minus two logical events [Ref. 14 ]. The application 

of this limit to processes is that the number of basis paths 

through a process should be limited to seven. Such a limit 
will aid in testing and maintenance due to the ability of 
the maintenance personnel to review the design and quickly 
grasp the purpose of a process. This application has been 
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validated by a software reliability study [Ref, 16] which 
demonstrated that procedures of already coded software with 
10 or more basis paths accounted for a much greater share of 
the errors. When processes are coded and compiled, their 
complexity will increase by 2 or 3; therefore, in the soft- 
ware design the complexity should be seven basis paths. 

The theory behind the complexity metric is based on a 
definition and theorem from graph theory. 

Definition 1. The cyclomatic number v(G) of a graph G 
with n vertices, e edges, and 1 connected component 
results in the equation: 

v(G) = e- n+1 (5.1) 

Vertices are also known as nodes and an edge can be consid- 
ered a path from one node to another. 

Theorem 1. In a strongly connected graph, the cyclo- 
matic number is equal to the maximum number of linearly 
independent paths. 

A strongly connected graph is one in which there is a 
single entry point and a single exit point. All paths go 
from the entry point to the exit point. Furthermore there is 
a path from the exit point to the entry point. A module can 
be considered to be represented by a strongly connected 
graph because there is a single entry point from the calling 
module and the module returns control to that entry point 
when it is through processing. 

When a control graph is drawn to represent the flew of 
control through a module, there is usually no indication of 
the path from the ending point to the entry point. McCabe 
remarks that this edge does not have to be drawn in, hut 



that it may be accounted for by modifying equation 5.1 
resulting in: 

v (G) = (e + 1) - n + 1 (5.2) 



or 



v (G) = e - n + 2 (5.3) 

Application of Theorem 1 to Graph G in Figure 5. 1 shows 
that v (G) is 5. This indicates that there is a basis set of 




Figure 5. 1 Graph G. 

five independent paths from node 'a* to node ’1’. There is 
no one correct set cf independent paths, but there is a 
basis of five paths. For example, there could be iterations 
of a loop within the module. The identification of the 
number of paths in the basis set does not tell how many 
iterations as the loop should be processed; that is 
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determined by data conditions at the decision points. Two 
examples of sets of basis paths for figure 5.1 are shown in 
table 6. 



TABLE 6 

Two sets of Basis Paths 



Set # 1 



hi: abcegheikl 
b2: abdfikl 
b3: abceikl 
b4: abceghl 
b 5: abdfgkl 



Set # 2 



abdf jkl 
abceikl 
abdfikl 
a be (egh) 3 eikl 
abc (egh) 4 1 



| The notation (egh) 3 means to 
literate the loop (egh) 3 times 



E. PROCESS DESCRIPTIONS 
1 . Model Bu ild ing 

The purpose of these processes is to construct a 
format for new factors or groupings of factors. If it is a 
grouping of factors being constructed then identify the 
groups, the sub-groups, the group, sub-group, and factor 
coefficients (weights), each groups level within the model, 
and the sub-groups and factors of which they are composed. 
If there are new factors being formatted then obtain their 
factor identifiers, factor types, characteristics, and the 
subjective impact of the world and the factor itself upon 
the factor. If there are any factors which impact upon the 
factor being formatted then obtain their factor identifiers 
and their subjective impact upon the factor being formatted. 
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a. 



Scoring Mcdel Construction 



Get the Factors (or Factor) which the manager 
wishes to be part of a model or which will be forecast or 
analyzed at a later time. 



Inputs: MODEL_ID 

GROUP 
FACTOR_ID 
SU3_G ROUP 

Outputs: MODEL_STRUCTURE 
FACTOR ID 



Source: Manager 

Manager 
Ma nager 
Process 1.2 

Destination: MODE L_ STRUCTURE 

File 

Process 1.2 



b. Sub-Group Organization 

Arrange Factors in Sub-Groups. Assign each 
Factor a weighting value and each Sub-Group a weighting 
value. Criteria for placing factors together in a Sub-Group 
are whether they are both either "desirable" or "undesi- 
rable" and that they can be traded off against one another. 
Otherwise they are in separate Sub-Groups. There is no limit 
to the number of Sub-Groups or Factors in a Sub-Group. 
However, single Factors do have to be assigned to a 
Sub-Group. 



Inputs: FACTOR_ID 

SUB_GROUP_ID 
SU3_GR0UP_ WEIGHT 
FACTOR_W EIGHT 

Outputs: SUB_GROUP 
FACTOR ID 



Source: Process 1.1 
Manager 
Manager 
Manager 

Destination: Process 1.1 
Process 1.3 
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c. Addition to Factor File 



If a Factor is a new Factor then get all infor- 
mation necessary for use in later analyzing or forecasting 
it. 



Inputs: FACTOR_ID 
FACTOR 

Outputs: FACTOR 



Source: Process 1.2 
Manager 

Destination: FACTOR File 



2 . Model M an agem ent 



The purpose of this process is to interpret the user 
command and forward the selection of the user for either 
analyzing or forecasting of the factor or model selected. 
Check to see if the selected factor or model is in the data- 
base. Any default values of the selection are set and the 
overall validity of the user’s selection is verified. If it 
is not valid the user is notified of that fact and allowed 
to reenter a selection command. 

a. Model Validation 



Ensure that the user made a valid 
options in his selection command. 



selection of 



Inputs: USER_SELECT 

USER_SELECT 
MODEL_STR UCTURE 
FIR M_SE1ECI 
VALIDATION 

Outputs: FIRM_SELECT 
FIR M_SELECT 
FACTOR_ID 
FIRM SELECT 



Source: Manager 

Process 6 
Process 2.2 
Process 2.3 
Process 2.2 

Destination: Process 4 
Process 6 
Process 5 
Process 2. 2 
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b. 



Set Default Values 



Provide default values for any parameters not 
specified by the manager. These default values are a period 
of the forecast using data from 15 years prior to the 
present date to 15 years beyond the present date into the 
future. The default interval is one year. For the MoDte 
Carlo selections the default number of iterations is 100. 



Inputs: 0 SER_SELECT 
TODA YS_DAT I 
MODEL TROCTURE 



Source: Process 2. 1 

Calendar 

MODEL STRUCTURE File 



Outputs: FIRM_SELECT 



Destination: Process 2.1 



c. Ensure Sufficient Data Available 



Check the Factor File to ensure that there are 
at least 3 data points within the user specified time period 
for each Factor necessary to the forecast. If the selection 
is for a cross-impact-analysis then this process is not 
necessary. 



Inputs: FIRM_SELEC T 
FACTOR 
FACTOR ID 



Source: Process 2.1 
FACTOR File 
Process 2 . 1 



Outputs: VALIDATION 



Destination: Process 2.1 



3 • En tr v 

This process allows operators to add values tc the 
factors in the Factor file. It is a screen formatted entry 
and allows little leeway for the operator. Errors are 
possible if the operator enters the wrong units for the 
ELE ME NT_ VALUE in spite of the prompting by the process. 



Inputs: FACTOR_ID 

DATE_0 FJDBSERVATION 
ELEMENT SOURCE 
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Source: Operator 
Operator 
Operator 



Operator 
Calendar 
FACTOR File 



ELEMENT_ VALUE 
DATE_OF_ENTEY 
UNITS 

Outputs: ELEMENT_ENTRY Destination: FACTOR File 
ENTRY_SCR EEN Operator 

4 . For eca st 

This group of processes execute the forecast of the 
model or factor selected by the user. The forecast is made 
by fitting five types of curves to the observed data. The 
curve with the highest correlation coefficient is utilized 
for the forecast. A default confidence interval of 50% is 
applied for the forecast. The results of the forecast are 
provided to the manager in a tabular format. If individual 
factors are forecast then the results are placed in the 
Factor file, with an ELEMENT_ANALYSI S of "Estimate", 
ELE ME NT_SOURCE is the CURVE used for the forecast, and 
EATE_CF_ENTR Y and DATE_0F_0BSERV AT ION are the date and time 
the forecast was completed. 

In the case of forecasting models three possible 
combinations are available. If all of the factors which make 
up the model have a factor limit then a model limit can then 
be calculated by utilizing the factor limit in place of the 
factor values in the scoring model and executing the model. 
This would enable Pearl and Gompertz curves to be calcu- 
lated, because these curves require an upper limit to 
growth. The model can then be executed as normal with the 
model limit used in these two equations in place of the 
factor limit. If some factors in a model have no factor 
limit then only the linear, logarithmic, and double loga- 
rithmic curves are available for fitting. 

There is also the option of forecasting each indi- 
vidual factor along the curve with the best fit and then 
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substituting the estimated values for each factor in the 
model. When observed data is not available then this is 
carried out through a Monte Carlo simulation using a random 
distribution between the upper and lower confidence limits 
of the estimate. 

a. Limit Choices 



Determine the beginning and ending time of each 
interval of the user's request. 



Inputs: FIRM_S ELECT 

MODEL_ STRUCTURE 
FACTOR_LIM IT 

Outputs: BAR E_ FACT CE_ VIEW 
EAR E_ FAC TCR_ VIEW 
MODEL_STRUCTURE 
MODEL STRUCTURE 



Source: Process 2 

MOD EL_STRUCTURE File 
FACTOR File 

Destination: Process 4.1.3 
Process 4.1.2 
Process 4.1.2 
Process 4.1.4 



fc. Check For Model Limit 



Check to see if Model-Limit can be calculated 
from data available. If all Factors in a model have a 
Factor-Limit then a Model-Limit can be calculated. 



Inputs: MO DEL_ STRUCTURE 
FACTOR_LIM IT 

Outputs: MODEL_LIMIT 

c. Calculate the 



Source: Process 4.1.1 
Process 4.1.1 

Destination: Process 4. 

Model-Limi t 
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Calculate the Model-Limit using the 

Factor-Limits for each Factor in the model and using the 
Model-Structure of the designated Model-Id. 

Inputs: MODEL_STR UCTUR E Source: Process 4. 1.2.1 

FACTOR_LIM IT Process 4. 1.2.1 

Outputs: MODEL_LIMIT Destination: Process 4.1.4 
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Screen Factor Values 



Screen Factor File for historical data within an 
interval. Calculate the average of the values and note the 
number cf values in each interval and the last interval 
which has any historical data in it. 

Inputs: BARE_FACTOR_VIEW Source: Process 4.1.1 
ELEMENT VALUE FACTOR File 



Outputs: FACTOR_VIEW 

FACTOR VIEW 



Destination: Process 4.1.4 
Process 4.3 



e. Scoring Mcdel 



Ensure an interval has at least 
in it prior to calculating the Model-Score, 
data points, go to the next interval. 



one data point 
If there are no 



Inputs; MODEL_LIMI T 

MODEL_STRUCTURE 
FACTOR_VIE W 
MCDEL SCORE 



Source: Process 4 
Process 4 
Process 4 
Process 4 



1.2 
1 . 1 
1.3 
1.4.2 



Outputs: MODEL_STR UCTURE 
AVG_V ALUE 
MODEL VIEW 



Destination: Process 4. 1.4.2 
Process 4. 1.4.2 
Process 4.3 



f. Calculate Model-Sccre 



Calculate score of a single interval cf a model 
using the Model- Structure and the Avg-Values passed to it. 
The Factors which make up each Sub-Group are multiplied by 
their Factor- We ight s and then summed together. All 
Sub-Groups are multiplied by their Sub-Group Weights. The 
Sub-Groups which are the components of each Group are multi- 
plied together and then multiplied by the Group-Weights. 
Desirable Groups are divided by undesirable Groups. 
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Overriding Groups multiply the entire model. This product is 
the Hcdel-Score. 



Inputs: M ODE L_ STRUCTURE Source: Process 4.1.4. 1 

AVG_VALUE Process 4. 1.4.1 

Outputs: MODEL_SCORE Destination: Process 4. 1.4.1 

g. Initialize Functions 

Determine the set cf formulas which will be used 
to convert observed data into a linear form. The possible 
five curves are the Pearl curve, Gompertz curve, linear (no 
change) , a logarithmic curve using the natural logarithm cf 
the dependent variable (the element-value), and a double- 
logarithmic curve using the natural logarithm of both the 
dependent (element- value) and independent variable 
(observation-date) . If there are no Factor or Model Limits 
then the Pearl and Gcmpertz curves can not be utilized. 



Inputs: MODEL_VIEW 
FACTOR VIEFI 



Source: Process 4.1 
P rocess 4 . 1 



Outputs: DATA_POINTS 
AVG_VALUE 
END_INTER VAL 
CURVE 
LIMIT 



Destination : 



Process 4. 3. 1 . 3 
Process 4. 3. 1.2 
Process 4. 3. 1 .2 
Process 4. 3 . 1 .2 
Process 4. 3. 1 . 2 



h. Calculate Curve Functions 



Adjust the Avg-Values and Observation-Dates into 
a form which may be linear using the Gompertz, Pearl, 
Logarithmic, or Double-Logarithmic equations. 



Inputs: LIMIT 

A VG_V ALU E 
END_INTER V AI 
CURVE 



Source: Process 4. 3. 1.1 
P rocess 4 . 3 . 1 . 1 
Process 4 . 3 . 1 . 1 
Process 4 . 3. 1 . 1 
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Outputs: DEPENDENT 
INDEPENDENT 



Destination: Process 4.3. 1.3 
Process 4. 3 . 1 . 3 



i. Calculate Regression 



Calculate A, B, the correlation coefficient, and 
the standard error cf 3 through simple regression. The 
dependent variable (an adjusted or unadjusted Element- Value) 
is regressed on the independent variable (an adjusted or 
unadjusted Observation- Date) . 



Inputs: DEPENDENT Source: Process 4. 3. 1.1 

DATA_POINTS Process 4.3. 1.1 

INDEPENDENT Process 4. 3. 1.1 

LAST OBSERVED INTERVAL Process 4.3. 1.1 



Outputs: REGRESS_ ANALYSIS 
REGRESS_A NALYSIS 
REGRESS_ANALYSIS 
REGR ESS_A NALYS IS 
REGRESS ANALYSIS 



Destination: Process 4.3.2 
Process 4.3.3 
Process 4.3.4 
Process 4.3.5 
Process 4.3.6 



j. Pearl Curve Forecast 

Generate estimates of data over the period in 
which data was observed using a Pearl curve formula, then 
calculate the estimated value for the data with an upper and 
lower limit for a 50 % confidence interval. This information 
is provided for each interval from the end of observed data 
to the End-Period of the user reguest. 



Inputs: VARIATE 

IDENTIFIER 
REGRESS_AN AIYSIS 
FACTOR_VIEW 
MODEL VIEW 



Source: Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 



Outputs: EXP ANDED_ FCDEL_VIEW Destination: Manager 
EXPAN DED_F ACTOR_VIEW Manager 
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EXPANDED FACTOR VIEW 



Process 4.3.1 



k. Gompertz Curve Forecast 



Generate estimates of data over the period in 
which data was observed using a Gompertz curve formula, then 
calculate the estimated value for the data with an upper and 
lower limit for a 50$ confidence interval. This information 
is provided for each interval from the end of observed data 
to the End-Period of the user reguest. 



Inputs: VARIATE 

IDENTIFIER 
REGRESS_ANAIYSIS 
FACTOR_VIE W 
MODEL VIEW 



Source: Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 



Manager 
Manager 
Process 4.3.1 

1. Linear Curve Forecast 



Outputs: EXP ANDED_ MCDEL_VIEW Destination: 

EXP ANDED_ FACTOR_V IEW 
EXPANDED FACTOR VIEW 



Generate estimates of data over the period in 
which data was observed using a Linear curve formula, then 
calculate the estimated value for the data with an upper and 
lower limit for a 50$ confidence interval. This information 
is provided for each interval from the end of observed data 
to the End-Period of the user reguest. 



Inputs: VARIATE 

IDENTIFIER 
REGR ESS_AN AIYSIS 
FACTOR_VIEW 
MODEL VIEW 



Source: Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 



Outputs: EXP ANDED_MCDEL_VI EW Destination: Manager 

EXP AN DED_FACTOR_VIEW Manager 

EXPANDED FACTOR VIEW Process 4.3.1 
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m. Log Curve Forecast 



Generate estimates of data over the period in 
which data was observed using a Logarithmic curve formula, 
then calculate the estimated value for the data with an 
upper and lower limit for a 50% confidence interval. This 
information is provided for each interval from the end of 



observed 


data to the End-Period of the 


user request. 


Inputs: 


VARIATE Source: 


Process 


4.3.1 




IDENTIFIER 


Process 


4.3. 1 




REGRESS_AN AIYSIS 


Process 


4.3. 1 




FACTOR_VIEW 


Process 


4.3. 1 




MODEL_VIEW 


Process 


4.3.1 



Outputs: EXP ANDED_MCDEL_VIEW Destination: Manager 

EXPANDED_FACTOR_VIEW Manager 

EXPANDED FACTOR VIEW Process 4.3.1 



n. Double-Log Curve Forecast 



Generate estimates of data over the period in 
which data was observed using a Double-Logarithmic curve 
formula, then calculate the estimated value for the data 
with an upper and lower limit for a 50% confidence interval. 
This information is provided for each interval from the end 
of observed data to the End-Period of the user request. 



Inputs: 



Outputs 



VARIATE 


Source: Process 


4.3. 1 


IDENTIFIER 


Process 


4.3.1 


REGRESS_ AN AIYSIS 


Process 


4.3. 1 


FACTOR_VIEW 


Process 


4.3.1 


MODEL_VIEW 


Process 


4.3. 1 


EXP ANDED_MCDEL_VIEW 


Des tinati on : 


Ma nager 


EXP ANDED_FACTOR_V IEW 




Manager 



EXPANDED FACTOR VIEW Process 4.3.1 
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Monte Carlo 



o. 



Provide the actual Model-Score and the estimated 
Model-Sccre over the intervals with observed data. The esti- 
mate is arrived at through use of the estimated factor 
values for each Factor in the model substituted in a scoring 
model. For the intervals with no observed data a 50% confi- 
dence interval is established using the upper and lower 
estimates for each Factor of the model and substituting them 
into a scoring model. Then, for number of times specified by 
the user, a random value between the upper and lower esti- 
mates for each Factor is used for calculating the 
Model-Score. 



Inputs: FIRM_S ELECT 

EXPANDED_FACTOR_VIEW 
MODEL_VIEW 
M ODE L_ STRUCTURE 
MODEL SCORE 



Source: Process 4.1 
Process 4.3 
Process 4 . 1 
Process 4 . 1 
Process 4.4.2 



Outputs: MONTECARLC_FORECAST Destination: Manager 

MODEL_STR UCTURE Process 4.4.2 

AVG VALUE Process 4.4.2 



p. Calculate Model Score 



Calculate score of a single interval of a model 
using the Model-Structure and the Avg-Values passed to it. 
The Factors which make up each Sub-Group are multiplied by 
their Factor-Weights and then summed together. All 
Sub-Groups are multiplied by their Sub-Group Weights. The 
Sub-Groups which are the components of each Group are multi- 
plied together and then multiplied by the Gr ou p-Weights. 
Desirable Groups are divided by undesirable Groups. 
Overriding Groups multiply the entire model. This product is 
the Model-Score. 



Inputs: MCDEL_STRUCTURE Source: Process 4.4.1 
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AVG VALUE 



Process 4.4.1 



Outputs: MODEL_SCORE Destination: Process 4.4.1 

5 ♦ Cross Im pa ct A nalys is 

This process utilizes the simple cross impact anal- 
ysis model devised fcy Kane as discussed in [Ref. 2]. It 
searches the database for the values it requires and does 
not require any interaction by the user. Any changes tc the 
model will be made in the Model Management process. 

a. Cross Impact 

Construct a Cross-Impact-Matrix of Factors which 
impact on a single object Factor. This matrix also includes 
the impacts of the other Factors upon each other. The impact 
of the cutside world only impacts upon the Factors; the 
Factors do not impact upon the outside world. 

Inputs: FACTOR_ID Source: Process 2.0 

IMPACT_FACTCRS FACTOR File 

FACTO R_I MPACTS FACTOR File 

Outputs: CROSS_IMPACT_MATRIX Destination: Manager 

CRO SS_IMPACT_MATRIX Process 5.2 

b. Calculate Impact 

Over a relative period of time calculate the 
cumulative effects of the values of the Cross-Impact-Matrix 
upon a set of subjective Initial-Values provide by the 
manager for each Factor. 

Inputs: CROSS_IMPACT_MATRIX Source: Process 5.1 
IN IT I AL_V ALUE Manager 

Outputs: RELATIVE_TIME Destination: Manager 

VALUE Manager 
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6 • Model Ch ange 



The user may change selected variables within the 
model which has most recently been executed and then execute 
it again. For a model forecast the Group-Weight , 
Sub-Group-Weight, and Factor-Weights may be changed. If 
desired, the modified model may be given a new name and 
placed in the Model-Structure file. The Factor-Limit of a 
Factor or of Factors in a model may be changed and the model 
run again. The selection parameters may be altered to change 
the time period looked at, the interval within the time 
period or, if the selection was for a model, a Monte Carlo 
forecast rather than a regular forecast (and vice versa) may 
be chosen. 



Inputs: INITI AL_V AI OE 
FACTOR_VIEW 
M ODE L_ STRUCTURE 
CROS S_IMPACT_MATR I X 
FIRM_S ELECT 
GROUP_WEIGHT 
SUB_GROUP_ WEIGHT 
FACTOR_WEIGHT 
FACTOR_LIMIT 
MODEL_ID 

Outputs: MODEL_STRUCTURE 
MODEL_STRUCTURE 

FACTOR_VI EW 
CROSS_IMPACT_MATRI X 
INITIAL VALUE 



Source: Process 5 
Process 4 
Process 4 
Process 5 
Process 2 
Manager 
M an a g er 
Manager 
Manager 
Manager 

Destination: Process 4 

MODEL_STRUCTURE 

File 

Process 4 
Process 5 
Process 5 
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VI. APPLICATIONS OF THE DSS 



The 


ISDN concept is 


the 


integration 


of 


digital voice. 


circ uit- 


switched data. 


and 


packet -sw itched 


data 


networks 


into a 


single network. 


The 


user of an 


ISDN 


would 


not be 



aware of which of these types of networks would be utilized 
to complete a connection to a destination. The network would 
select the required type of network, the choice of which 
would be transparent to the user, but is accessed at a 
single point. An ISDN architecture for the national backbone 
and distribution telecommunications systems could be desir- 
able by the NCS as it would simplify the problem of inte- 
grating the present mix of communica tions networks in a 
national emergency. 

The rate at which an ISDN architecture will evolve in 
the United States can not easily be mandated by regulation 
due to the increasing number of private companies and 
government agencies involved in construction and maintenance 
of telecommunications systems. As pointed out in Chapter 1, 
the impetus for growth of a technology comes from a need for 
that technology. In the United States, it is estimated that 
private users provide 85% of the needs driving the evolution 
of the common carrier network. Only 20% of the private users 
provide 80% of the use of the common carrier networks 
[Ref. 17 ]. Therefore, to forecast the growth of ISDN tech- 
nology, it is necessary for the manager to forecast the need 
for an ISDN by private users. 

The forecast DSS described in this paper can be utilized 
to forecast that user need for an ISDN. The method for doing 
this is for the NCS to collect data on the number of Private 
Branch Exchanges (PBX's) with digital capable microwave, 
optical fiber, or copper T-carrier direct tie-lines to tell 
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or tandem switches with direct access to the digital tack- 
tone system. This data can be expressed as a number of tie- 
lines installed or as a percentage of installed PBX’s with 
the tie-lines. This is an indicator that network users want 
to bypass the local distribution systems which are difficult 
to use for high speed digital communications. The number of 
PBX’s with tie-lines can be entered into the database of the 
DSS. A forecast can be generated of this data by extrapo- 
lating along the growth curve with the best fit to the data. 
This curve fitting is performed by the DSS and the results 
of the forecast are stored in the DSS database for later 
comparison and are also presented to the user in either 
tabular cr graphical form. 

The above example is one of an accelerator for techno- 
logical growth of ISDN architectures. It would also be 
desirable to forecast constraints on the development and 
implementation of this technology. The number of engineers 
and maintenance personnel trained to install and maintain an 
ISDN is a definite constraint on implementation of an ISDN 
architecture in the Onited States. The data on the number of 
such ISDN trained personnel can be collected and forecast 
using the DSS. 

After a number of accelerators and constraints have been 
collected, a cross impact analysis of the factors upon each 
other can be performed by the DSS. An analysis of this type 
could demonstrate the relative impact of different variables 
upon each other to obtain an approximation of the relative 
time required to achieve a desired result. For example, the 
impacts of digital communication media cost, the number of 
ISDN trained personnel, and the competition to provide 
digital services upon ISDN technology growth can be modeled. 
The DSS is executed with the impacts as subjective values 
and are defined as desirable or negative impacts upon ISDN 
technology. 
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An example cross impact matrix is given in Table 7. The 
variables listed in the table are: 

1. Digital communications media cost = 1 M' 

2. Number of ISDN trained personnel = ’P’ 

3. Ccmpetition to provide digital services = ’C' 

4. Growth rate of ISDN technology = ’3’ 

The cross impact matrix indicates that the cost of communi- 
cations impacts negatively on the rate of growth, while the 
training of more personnel facilitates the training of even 
more personnel. The advantage of this model is that it 
demonstrates the relative impact that a combination of vari- 
ables can have on the growth rates of other variables. 
Figure 6.1 is the result of executing the model with the 
values from the cross impact matrix of Table 7. 



TABLE 7 

Sample Cross Impact Matrix 
Values of Impacting Factors 

Outside 





M 


E 


C 


G 


World 


M 


-.10 


0.00 


-.0 1 


-.01 


0.01 


P 


0. 00 


0. 02 


0.01 


0. 02 


0. 01 


C 


-.02 


-. 02 


-. 10 


0.02 


0.01 


G 


-. 20 


-. 40 


0.02 


0.02 


0.01 
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Time Subjective Values 
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Figure 6. 1 Output of Cross Impact Analysis. 
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VII. CONCLUSIONS 



The National Communications System has been tasked with 
the overall responsibility for planning a national security/ 
emergency preparedness telecommunications system [Ref. 17]. 
An automated decision support system which can aid NCS 
managers in making effective forecasts of telecommunications 
technology, prices and costs would be an invaluable tool for 
the conduct of this planning. This work has described the 
logical design of such a system. The design is general 
enough to allow maximum flexibility in the eventual conver- 
sion to a physical, coded implementation. It will not be 
difficult to code this design in a higher order language 
such as Ada, COBOL, or BASIC. More importantly, the logical 
design of this DSS lends itself toward implementation 
utilizing a fourth generation language such as FOCUS or 
NOMAD. The ability of these type of packages to access data 
through a database- type format allows a non-programmer to 
take this design and create a database which can be accessed 
by simple routines written in the generic language which 
accompanies these packages. 

Furthermore, the design of this forecast DSS can be 
implemented on any size computer from a desktop microcom- 
puter up to a large mainframe. The designation cf a 
specific system to run this package at this stage of the 
design is not necessary nor is it desirable. The end product 
that a user should be looking for is an acceptable logical 
design, not an up and running system. With a logical design 
the user can change computer systems without having to have 
all of his software redesigned. It will be simple to have it 
coded for the new system or implement it himself with a 
fourth generation package as described earlier. 



The modular design of lis system enables expansion of 
the forecast routines w ~h little effort. The models 
selected for this design were chosen for their simplicity 
and ease of understanding by the user. A complex econometric 
model may be more accurate (though that has been debated by 
professionals in the field [Ref. 18] ), but the simplicity 
of simple regression models is more intuitive to the 
manager. Two possible simple models could be added, an expo- 
nential smoothing model, and a moving average model. However 
the seasonal or normalizing techniques which accompany these 
models are not so simple and depend on many more assumptions 
than a simple regression extrapolation. Through the use of 
the scoring model construction technique, the manager can 
build simple multivariable bootstrap models. Such models 
have been shown to model reality to a remarkable degree 
[Ref. 18]. In any case, this system’s strict adherence to 
structured techniques and modularity would facilitate any 
future modification or expansion brought about by the 
dynamic nature of the telecommunications environment and the 
possibility of changes in overall system requirements. 
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APPENDIX a 

ESSENTIALS OF STBUCTURED DESIGN 



Stevens et al. [Ref. 19] introduced the concept of 
structured design as a comprehensive method for reducing the 
growing complexity of program design. Because it is not a 
true methodology, it is used most effectively in consonance 
with other techniques, such as structured programming, 
structured analysis, and HIPO hierarchy charts. The key to 
structured design is reducing the logical view of the system 
into simple pieces, called modules, that can be readily 
understood and hence constructed. The rationale behind this 
concept, common with most modern software design techniques, 
lies with principles of behavioral science regarding the 
human ability to comprehend and solve problems faster when 
they are of manageable size and complexity. These princi- 
ples were the basis for top-down design, which calls for 
decomposing large, complex problems into smaller, less 
complex problems, until the original problem has been 
expressed as a combination of many, small, solvable prob- 
lems. However, top-down design alone is not sufficient for 
ensuring modules that are easy to maintain and modify. 
Structured design includes the concept of top-down design, 
along with other strategies and heuristics. Among these are 
coupling and cohesion. 

Coupling is a measure of the strength of association 
between separate modules within a system. The greater the 
degree of coupling, the harder it is to understand, change, 
or correct a module and hence the more complex and compli- 
cated the system. One goal of structured design is to 
create modules with coupling as weak as possible. This can 
be achieved, at least in theory, by designing the module 



63 



interface to be simple and obvious and ensuring the connec- 
tion between modules is to the normal module interface (the 
entry point) rather than to module internal components. 

Modules share a common environment when they interface 
with the same storage area, data region or device. Common 
environments often provide complex paths along which errors 
can travel when a change is made to one module. When common 
environments are originally designed into a system, add-on 
modules will also be forced to interface via the common 
environment, further degrading the product. Limiting common 
environment access to the smallest possible subset of 
modules tends to minimize this potential problem. Another 
method to achieve lew coupling is to restrict interface 
connections to obvious relationships and avoid those that 
are inferred. Thus, connections which refer to a module as 
a whole require less coupling than those which refer to an 
internal component of a module. This latter case is called 
pathological connection, and is one of the strongest forms 
of coupling between modules. It can be avoided by ensuring 
a subroutine executes only when it is called formally by a 
module, it operates strictly on data passed by the calling 
module, only that data essential to the performance of its 
task is passed to the subroutine, and all results of its 
operations are returned to the calling module. 

Cohesion is defined as the strength of association of 
the elements within a module, and is measured by a term 
called binding. The goal is to strive for high binding, 
which directly results in reduced coupling by minimizing the 
relat ion ships among modules. The levels of cohesion may be 
addressed separately, scaled from low to high, and although 
a module may exhibit multiple levels of binding, the highest 
that may be applied determines the module level. 

1. Coincidental binding means there is no meaningful 
relationship among the internal elements of a module. 
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It usually stems from haphazard attempts at breaking 
code up into "modules" or consolidating duplicate 
ceding from several modules into one "module". 

2. Logical binding means there exists some kind of 
logical relationship among the elements of a module. 
It often results from "cute", difficult to modify, 
shared code, or from passing unnecessary arguments. 

3. Temporal binding means the elements are logically 
related also in time. Such elements are executed 
during a common period of time. The reason such 
modules are higher on the cohesion scale is that all 
the elements are at least executed at once. 

4. Communicational binding means that elements are 
related further to the same input/output data set. 

5. Sequential binding means that elements within a 
module are processed sequentially. It usually 
results from literal transformation of flowchart 
procedural blocks to modules. However, procedural 
processes can encompass more than one function. 

6. Functional binding means all the elements of a module 
are related to the performance of a single function. 
It is the strongest level of binding. In practice, 
the determination of what exactly constitutes a func- 
tion is a difficult task, further compounded by the 
dilemma of deciding how far to divide functionally 
bound subfunctions. 

Although there may well be a basic tradeoff to be 
confronted between "structural design" modules and 
execution/memory overhead, there are a number of reasons why 
a structured design may, indeed, enhance execution time/ 
memory space required. The major reasons are: 

1. Error modules (called "optional") may never be called 
from memory. 
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Other, well- designed modules may only be executed a 
minimum number of times. 

3. Structured design reduces the amount of duplicate or 
redundant code. 

The structured design process is divided into two 
phases: general program design and detailed design. General 
program design is described as deciding what the program 
functions will be, and detailed design as deciding how the 
functions will be implemented. The overall design goal 
remains the structure of functionally bound, simply 
connected modules. The technigue is simply top-down, 
modular, hierarchical with a unique graphical format. The 
following guidelines may be helpful when utilizing the 
structured design process: 

1. In order to enhance maintainability, ensure the 
structure of the design matches the structure of the 
problem. Subsequent changes to the problem will then 
affect a minimal number of modules. 

2. Strive for simple designs where the scope of effect 

of a decision is restricted to the scope of control 
of the module containing the decision. This is 
accomplished by either moving the decision element up 
in the structure chart, or by moving the entire 

module containing the decision so that it falls 

within the scope of control. 

3. Use module size as an indicator of potential prob- 
lems. A module that is extremely small may not 

perform a complete function. A module that is 
extremely large may include more than one function. 

4. It is acceptable to design modules that return binary 
error or end-cf-file flags. However, the same module 
should not be concerned with error recovery. 

5. Duplicate code may, under certain circumstances, be 
acceptable. Luplicate functions, however, should be 
eliminated. 
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6. Particular data structures should be isolated in a 
minimum number of modules. This will facilitate 
module changes due to subsequent alterations in that 
data structure's specifications. 

7. Minimize the number of parameters passed between 
modules. The goal is tc pass only that data required 
by the module to accomplish its function. 

There are several important variations of the basic 
structured design methodology. DeMarco [Ref. 12] proposes 
an approach that begins with the codification of the func- 
tional specif ication , or translating the prose specification 
into working fixed-fcrmat documents (data flow diagrams, 
data dictionary, transform descriptions, data structure 
chart). This step cculd actually be considered "structured 
analysis". The next step is the derivation of the structure 
chart, a modular hierarchy chart which records major design 
decisions and philosophy. Structure charts are recommended 
rather than flowcharts because flowcharts violate the prin- 
ciple of information hiding by exposing critical design 
decisions too early in the design process (for example, in 
what order and under what conditions functions are 
performed) . Additionally, structure charts depict module 
connections and calling parameters, are smaller in size and 
generally more manageable. In the DeMarco version module 
design occurs next through construction of module descrip- 
tions. The final step is packaging the design, or shaping 
the logical design to accommodate the physical environment 
(machine, operating system, coding language, memory limita- 
tions, time restrictions). The key is to construct an 
environment-independent design first, maximizing cohesion 
and minimizing coupling, then impose packaging constraints 
so as to minimize degradation of product quality. An impor- 
tant structured design principle is to delay packaging as 
long as possible in order to "hide" the significant nature 
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of the design problem, to include algorithms, data struc- 
tures and other transformations. 

Enforcement of structured design techniques should 
significantly reduce the effort required for program modifi- 
cation and maintenance, if modules possess weak coupling and 
strong cohesion. Similarly, modules may be programmed, 
tested, and even optimized independently using these tech- 
niques. Structured design should, as a minimum, provide for 
"predictable ' 1 modules. These are modules which perform 
identically and consistently each time they are called, 
given identical inputs. Predictable modules also tend to 
perform independently of their environment. It is not 
clear, however, that strict adherence to structured design 
will ultimately result in a "library" of generalized, 
application-independent modules that may be easily config- 
ured to implement any sophisticated, complex system. In the 
final analysis, structured design is a method, not a method- 
ology, and is to be used with other methods and tools to 
facilitate the design of programs. 
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APPENDIX B 

PROCESS MINI-SPECIFICATIONS 



**************************** ******** *********** ************* 

1.1 SCORING MODEL CONSTRUCTION 



Inputs: MODEL ID 

GROUP - 
FACTOR ID 
SUB_GROUP 

Outputs: M CD EL_ STRUCTURE 
FACTOR ID 



Source: Manager 

Manager 
Manager 
Process 1.2 

Destination: MODEL STRUCTURE 

File 

Process 1.2 



A. Identify FACTOR_IEs that relate to how well the 

technology performs. 

B. Eliminate overlays of ELEMENTS from the model that 

measure the same or very similar characteristics. 

D. For each FACTOR ID in the model 

E. Do SU3_GR0UP — ORGANIZATION 

F. End For. 

G. For each SUB GROUP ID 

H. If each SUB_GECUP is of such an overriding nature that 

it must be present or the sc ere of the model equals 
zero then 

I. Assign this SUB GROUP to be the sole member of a GROJ P 

J. Assign this GROTJP a GROUP ID 

K. Assign a GFCUP LEVEL = 0 “ 

L. Assign a GRCUP~TYPE = "Override" 

£ X S6 

M. If SUB GROUP is desirable then 

N. Assign to a GROUP with GROUP TYPE = "Desirable" 

E Isg 

O. Assign to a GROUP with GROUP TYPE = "Undesirable". 

P. End If 

Q. End If 

R. End For 

S. For each GROUP 

T. If GROUP TYPE is not equal to "Override" then 

U. Assign a GPCUP ID. 

V. Assign a G FCUP - LE VEL = 1. 

W. End If 

X. End For 

Y. Assign each GROUP a subjective GROUP_WEIGHT. 

Z. Assign the model a M0DEL_ID. 
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TABLE 8 

Process 1.1 Basis Paths 



Complexity Metric: 7 

1 atcfgrsxyz 

2 ahcdef grsxyz 

3 atcf ghi jklgrsxyz 
h atcf ghmnpgrsxyz 

5 atcf ghmopgrsxyz 

6 atcf ghmopgrstwxyz 

7 atcf ghmopgrstuvwxyz 



******************** **************************************** 
1.2 S UB_GROUP ORGANIZATION 

Inputs: FACTOR ID Source: Process 1.1 

SOB GROUP ID Manager 

SUB - GROU P — W El GHT Manager 

FACT0R_WEIGHT Manager 

Outputs: SUB GROUP Destination: Process 1.1 

FACTOR ID Process 1.3 



A. 

E. 

C. 

D. 

E. 

F. 
G • 

H. 

I. 



Do ADDITION TO FACTOR File 

If FACTORS can be traded off against FACTORS in 
a SUB_GROUP then 

Assign FACTOR tc that same SUB GROUP. 

Assign a FACTOE_WEIGHT 
E 1 s© 

Assign FACTOR as sole member of a new SUB GROUP. 
Assign a FACTOR WEIGHT 
Assign a SUB GFtUP_ID. 

Assign a subjective SUB GROUP WEIGHT. 

End If ~ 
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TABLE 9 

Process 1.2 Basis Paths 

Complexity Metric: 2 

1 . alcdi 

2. abefghi 



1.3 ADDITION TO FACTOR FILE 

Inputs: FACTOR_ID Source: Process 1.2 
FACTOR Manager 

Outputs: FACTOR Destination: FACTOR File 



A. Check the FACTOR ID against the FACTOR File 
E. If it is not present then 

C. Get the FACTOR ID along with the FACTOR TYPE 
and CHARACTERISTIC from Manager 
If the FACTOR TYPE = "Objective" then 

Get the ONUS and the FACTOR LIMIT from Manager 
. End If 

. End If 

. Get FACTOR IMPACT of the FACTOR upon itself 
. Get FACTOR~IMPACT of the OUTSIDE WORLD upon the FACTOR 
. If there are FACTORS which impact on this FACTOR then 
. Provide the FACTOR IDs 

Do ADDITION TO FACTOR FILE 
. If these impacting FACTOR IDs are not already 

listed in the FACTOR File as impacting on the 
object FACTCR then 

. Get the subjective FACTOR IMPACT 

End If 
. End If 
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TABLE 10 

Process 1.3 Basis Paths 



Complexity Metric: 5 

1 . alghiip 

2. atcdefghijp 

3. atcdfghijp 
atghigklmnop 

5. alghijklmop 



$$$$$ $$$$$$$$$ $$$$$$ $ $ $ $ $ $ $ ^c^c. 

2.1 MCDEI VALIDATION 



Inputs: USER SELECT 

USER~SELECT 
MODE! STRUCTURE 
FIRM SELECT 
V ALIUATION 

Outputs: FIRM SELECT 
F IRM~ SELECT 
F IRM~ SELECT 
FACTOR ID 



Source: Manager 

Process 6 
Process 2.2 
Process 2.2 
Process 2.3 

Destination: Process 4 
Process 6 
Process 2.2 
Process 5 



A. If a FACTOR_ID is in the USER_S ELECT and CHOICE equals 
"Forecast" then 

E. If FACTOR ID is present in the FACTOR File then 

C. Do S ET - DEF AULTS 

D. Do ENSURE SUFFICIENT DATA AVAILABLE 

E. End If. 

Else 

F. If a MODEL ID is in the USER SELECT then 

G. Do SET UEFACLTS 

H. If CHOICE = "Cross Impact" then 

I. VALIDATION = "Not Valid" 

J. End If. 

K. If VALIDATION = "Valid" then 

L. Get the EACTOR IDs from the MODEL_STR UCTUR E 

M. For each FACTOR ID 

N. Do ENSURE SUTFICIENT DATA AVAILABLE 

C. End For 

F. End If. 

Q. End If. 

R. End If. 
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TABLE 11 

Process 2. 1 Basis Paths 



Complexity Metric: 7 

1. aler 

2. afccder 

3. afgr 

4. afghjkpgr 

5. afghiikpgr 

6. afghgklmnopgr 

7. afghgklmopgr 



*********************************************************** 



2.2 SET DEFAULT VALUES 

Inputs: USER SELECT 
TODAYS DATE 
M0DEL_5TRUCTURE 

Outputs: FIRM_SELECT 



Source: Process 2.1 

Calendar 

MODE L_STRUCTURE File 
Destination: Process 2.1 



A 

B 

C 

D 

E 

F 

G 

H 

I 

J 

K 

L 

M 

N 

0 

P 



S 

T 



VALIDATION = "Valid" 

If IDENTIFICATION = MODEL ID and 
MODEL STRUCTURE File then 
VALIDATION = "Net Valid" 

Else 

Get TODAYS DATE 
If BEGIN PERIOD = Null then 
BEGIN - PERIOD = TODAYS DATE 
End If. “ 

If END PERIOD = Null then 

END - P ERIOD = TODAYS DATE + 
End If 7 

If BEGIN PERIOD >= END PERIOD 
Selection is not valid 
End If. 

If INTERVAL = Null then 
INTERVAL = lyr 
End If. 

If CHOICE = "Mcnte Carlo" and 
ITERATIONS = 100 
End If. 

End If. 



MODEL ID is not in the 



- 15yrs 

1 5y rs 
then 



ITERATIONS = Null then 
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TABLE 12 

Process 2.2 Basis Paths 



Complexity Metric: 7 

1 . atct 

2. atdegh j kmnpgst 

3. atdergh jkmnpgst 

4. aldeghi ikranpgst 

5. atdegh j klmnpqst 

6. atdeghj kmnopgst 

7. atdeghg kmnpgrst 



***********************************#*****#********##***$:$£ ** * 
2.3 ENSURE SUFFICIENT DATA AVAILABLE 



Inputs: FIRM SELECT 
FACTOR 
FACTOR ID 



Source: Process 2.1 
FACTOR File 
Process 2. 1 



Outputs: VALIDATION 



Destination: Process 2. 1 



A. If CHOICE = "Monte Carlo" cr "Forecast" and at 
least three ELEMENT ENTRYs with an 
ELEMENT ANALYSIS equal to "Historical" 
are NOT present with DATE OF OBSERVATION 
between BEGIN FERIOD and 'END - PER 10 D then 
E. VALIDATION = "TIot Valid" 

C. End If. 







TABLE 13 






Process 


2.3 Basis Paths 




Complexity 


Metric : 2 






1 . ate 

2 . ac 






: 
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s*******^************************************ *************** 
3.0 ELEMENT ENTRY 



Inputs: FACTOR ID 

CATE OP OBSERVATION 



Source: Operator 



Operator 
Operator 
Operator 
Calen dar 

r 7l r rpn TJ rp 



ELEMENT - SOU RCE 
ELEMENT - VALUE 
LATE OF - ENTR Y 
UNITE - 



FACTOR File 



Outputs 



ELEMENT ENTRY 
ENTRY SCREEN 



Destination: FACTOR File 

Operator 



. If FACTOR ID is in FACTOR File then 
Display ENTRY SCREEN 
Enter DATE OF - CESERVATION 
Enter ELEMENT - SCURCE 
Enter ELEMENT - VALUE 
ELEMENT_ANALY5IS = "Historical" 

. Combine with DATE OF ENTRY and store in FACTOR File 
. End If - - 



TABLE 14 

Process 3.0 Basis Paths 



Complexity Metric: 2 

1 . ah 

2. atcdefgh 
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***************************$* 



**************************** 
4. 1- 1 LIMIT CHOICES 

Inputs; FIE M SELECT 

MODEr STRUCTU3E 
FACTOR_LIMIT 

outputs: BARE FACTOR VIEW 
BAF E” FACTOR” VIEW 
MODEL STRUCTURE 
MODEL”S TR UC TORE 



Source: Process 2 

MODEL STRUCTURE File 
FACTOR File 

Destination; Process 4.1.3 
Process 4.1.2 
Process 4.1.2 
Process 4.1.4 



A. INTERVAL NUMBER = 0 

B. END INTEKVAL(O) = BEGIN PERIOD 

C. While END INTERVAL (INTERVAL NUMBER) < END PERIOD 

D. INTERVAL NUMBER = INTERVAL NUMBER + 1 ” 

E. BEGIN INTERVAL (INTERVAL NUflBER) = 

END INTERV AL “(INTERVAL NUMBER - 1) 

F. END INTERVAL (INTERVAL NUMBER) = ” 

BEGIN INTERVAL (INTERVAL NUMBER) + INTERVAL 

G. End While. 

H. LAST INTERVAL = INTERVAL NUMBER 

I. If MCDEL_ID is in FIRM_SELECT and CHOICE = "Forecast” 

then 

J. For each FACTOR ID in MODEL STRUCTURE 

K. Do SCREEN FACTOR VALUES ” 

L. End For. 

M. Do CALCULATE MODEL LIMIT 

N. INTERVAL NUMBER = 1 

O. While INTERVAL NUMBER <= LAST OBSERVED INTERVAL 

P. Do SCORING ROD EL 

Q. INTERVAL NUMBER = INTERVAL NUMBER + 1 

R. End While. ” 

S. End If. 



TABLE 15 

Process 4.1.1 Basis Paths 



Complexity Metric: 5 

1. alcdefghis 

2. atcghis 

3. atcghij lmnors 

4. atcghigklmncrs 

5. ahcghig lmnopgrs 



76 



************************************************************ 
4. 1.2.1 CHECK FCR MCEEL LIMIT 



Inputs: 

Outputs 



MODEL STRUCTURE 
FACTOH_LIMIT 

MODEL LIMIT 



Source: Process 4.1.1 
Process 4.1.1 

Destination: Process 4.1.4 



A. For each FACTOR IE in MODEL STRUCTURE 

E. If FACTOR LITTI1 = Null then 

C. MODEL LIMIT = Null 

D. End If. “ 

£. End For. 

F. If MODEL LIMIT <> Null then 

G. Do CALCULATE MCDEL LIMIT 

H. End If. 



TABLE 16 

Process 4.1.2. 1 Basis Paths 



Complexity Metric: 4 

1. aefh 

2. atdefh 

3. alcdefh 

4. atcdefyh 
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4. 1.2.2 CALCULATE MODEL LIMIT 



Inputs: 

Outputs 



MODEL STRUCTURE 
FACTOR_LIMIT 

MODEL LIMIT 



Source: Process 4. 1.2.1 
Process 4. 1 . 2. 1 

Destination: Process 4.1.4 



A. For Each GROUP 

B. If GROUP LEVEL = 1 

C. For each SUB_GROUP 

D. Sum the value of the FACTOR LIMITS multiplied 

by the FACTOR WEIGHTS of each FACTOR ID 

E. Multiply this sum 3y the SUB GROUP WEIGHT" 

F. Remember this as the SUB_GROUP VALUE 

G. End For 

H. Multiply the SUB GROUP VALUES together 

I. Multiply the SUB"GROUP"VALUE by the 

GROUP WEIGHT - 

J. Remember Ihis as the GROUP VALUE 

K. End If. 

L. End For. 

M. If there are 2 groups with a GROUP LEVEL = 1 then 

N. DIVIDE THE GROUP VALUE of the GROUP which has a 

GROUP TYPE = - " Desirable" by the GROUP VALUE 
of the GROUP which has GROUP TYPE equal to 
"Undesirable" 

O. Remember this number as MODEL LIMIT 

P. End If 

Q. For each GROUP 

R. If GROUP LEVEL = 0 

S. GROUP - VALUE = FACTOR LIMIT * GROUP WEIGHT 

T. Multiply the GROUP VILUE times t he - MODEL_LIMIT 

U. Remember this result as the MODEL LIMIT 

V. End If. 

W. End For. 



TABLE 17 

Process 4. 1.2. 2 Basis Paths 



Complexity Metric: 7 

1 . almpqw 

2. almpqrvw 

3. atklmpgw 

4. almpgrstuvw 

5. alcghijklmpgw 

6. atcaefghi jk lmpgw 

7. almnopqw 
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****************************************** ******** ********** 
4.1.3 SCREEN FACTOR VALUES 



Inputs: EARE FACTOR VIEW 
EL EMENT_ VALUE 

Outputs: FACTOR VIEW 
FACTO R" VI EW 



Source: Process 4.1.1 
FACTOR File 

Destination: Process 4.1.4 
Process 4.3 



A. 


For each INTERVAL NUMBER 








B. 


If CATE OF OBSERVATION is greater than 


or ec 


jual 






to HEGIN INTERVAL (INTERVAL NUMBER) 


and ] 


Less 






than END"INTERVAL]lNTERVAL"NUMBER) 


then 






C. 


TOTAL = TOTAL + ELEMENT VALUE 








E. 


OBSERVED = CESERVED + 1“ 








E. 


LAST OBSERVED INTERVAL = INTERVAL NUMBER 






F. 


End If." 








G. 


AVG VALUE = TOTAL / OBSERVED 








H . 


End For. 












TABLE 18 






1 




Process 4.1.3 Basis Paths 










Conplexity Metric: 3 










1 . alf gh 

2. ah 










3. atcdefgh 
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** 3 C * ********************************************** ********** 

4. 1. 4. 1 SCORING MODEL 



Inputs 



MODEL LIMIT 



Source: Process 4.1.2 



MODEL-STRUCTURE 



FACTOR VIEW 

model Score 



Process 4.1.1 
Process 4.1.3 



r LUt/Coo ^ • i • J 

Process 4. 1.4.2 



Outputs: MODEL STRUCTURE 



Destination: Process 4. 1.4.2 



AVG VALUE 
MODEL VIEW 



Process 4. 1.4.2 
Process 4. 3 



. INTERVAL NUMBER = 1 

. While INTERVAL NUMBER <= LAST OBSERVED INTERVAL 
. GCOD INTERVAL =1 

. Fcr each FACT CF ID in model 

If OBSERVED = 0 then 
GOOD INTERVAL = 0 
End If .“ 

. End For. 

. If GOOD INTERVAL = 1 then 

. Do CALCULATE MODEL SCORE 

OBSERVE = 1 
Else 

OBSERVE = 0 
MODEL SCORE = 0 

. End If. 

INTERVAL NUMBER = INTERVAL NUMBER + 1 
End While “ 

. Combine data into MODEL VIEW 



Complexity Metric: 5 

1 . atpq 

2. atcdhilmnopg 

3. ahcdeghilmnopq 

4. abcdef ghilmnopg 

5. atcdefghi jknopq 



TABLE 19 

Process 4. 1.4.1 Basis Paths 
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************************************************************ 
4. 1.4.2 CALCULATE MODEL SCORE 



Inputs : 
Outputs 



MODEL STRUCTURE 
AVG_VXLUE 

MODEL SCORE 



Source: Process 4. 1.4.1 
Process 4.1.4. 1 

Destination; Process 4. 1.4.1 



A. For Each GROUP 

B. If GROUP LEVEL = 1 

C. For each SUE GROUP 

D. Sum the value of the AVG VALUES multiplied by 

the FACTOR WEIGHT of“each FACTOR IP 

E. Multiply this sum by the SUB GROUP WEIGHT 

F. Remember this as the SUB_GROUP_VALUE 

G. End For 

H. Multiply the SUB GROUP VALUES together 

I. Multiply the SUB~GROUP“V ALUE by the 

GROOP WEIGHT - 

J. Remember Ihis as the GROUP VALUE 

K. End If. 

I. End For. 

M. If there are 2 groups with a GROUP LEVEL = 1 then 

N. DIVIDE THE GROUP VALUE of the GlOUP which has a 

GROUP TYPE = - "Desirable" by the GROUP VALUE 
of the GROUP which has GROUP TYPE equal to 
"Undesirable" 

C. Remember this number as MODEL SCORE 

P. End If 

Q. For each GROUP 

R. If GROUP LEVEL = 0 

S. GFOU P — V ALU E = AVG VALUE * GROUP WEIGHT 

T. Multiply the GROUP VALUE times Ihe MODEL_SCORE 

U. Remember this result as the MODEL SCORE 

V. End If. 

W. End Eor. 



TABLE 20 

Process 4. 1.4. 2 Basis Paths 



Complexity Metric: 7 

1 . almpqw 

2. atklmpqw 

3. abcqhigklmpgw 

4. atcaefghi jklmpgw 

5. almnopqw 

6. almpqrvw 

7. almpqrstuvw 



81 



******************************************************* **** 
4.3. 1.1 INITIALIZE FUNCTIONS 



Inputs: MODEL VIEW 
EACTOEf VIEW 



Source: Process 4.1 
Process 4. 1 



Outputs: DATA POINTS 
AVG VALUE 
END - INTERVAL 
CURVE 
LIMIT 



Destination: Process 4.3. 1.3 
Process 4.3. 1.2 
Process 4.3. 1.2 
Process 4.3. 1.2 
Process 4.3. 1.2 



A. If FACTOR LIMIT = Null then 

B. PICK = Set [' linear’ | * Log • | * Double-Log* ] 

Else 

C. PICK = Set r * Pearl* | 1 Gompertz * | ' Linear ’ | ' Log ' | ' Douhle-Lo g » ] 

D. LIMIT = FACTOR LIMIT 

E. End If. 

F. For CURVE = FIRS T ’LAST of set PICK 

G. 1 = 0 

H. CCUNT = 1 

I. While COUNT <= LAST OBSERVED INTERVAL 

J. If OBSERVE (COUNTf > 0 then 

K. 1 = 1+1 

L. Do CURVE FUNCTION 

M. End If 

N. COUNT = COUNT + 1 

C. End While. 

P. DATA POINTS = I 

C. Do CALCULATE REGRESSION 

R. End For 

S. Co SELECT CURVE 



TABLE 21 

Process 4.3. 1.1 Basis Paths 



Complexity Metric: 5 

1. alefrs 

2. acdefrs 

3. atefghiopqrs 

4. atef ghi jmnopgrs 

5. alef ghigklmnopgrs 
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**************************************************:*:****:***#* 
4.3. 1.2 CALCULATE CURVE FUNCTIONS 



Inputs: LIMIT 



Inputs 



Source: Process 4.3. 1.1 



IT UL. C <c o ^ • J • I* I 

Process 4. 3 . 1 . 1 
Process 4.3. 1 . 1 
Process 4 . 3 . 1 . 1 



AVG VALUE 
END - INTERV AL 
CURVE 



Outputs: DEPENDENT 
INDEPENDENT 



Destination: Process 4.3. 1.3 
Process 4.3. 1.3 



A. Choose from the following: 

CURVE = Pearl 

DEPENDENT = IOG (LIMIT / AVG VALUE - 1) 
INDEPENDENT = END INTERVAL “ 

CURVE = Gompertz 

DEPENDENT = IOG (LOG (LIMIT / AVG VALUE ) ) 

INDEPENDENT = END INTERVAL 
CURVE = Linear 

DEPENDENT = AVG VALUE 
INDEPENDENT = EHD_INTER VAL 
CURVE = Logarithmic 

DEPENDENT = IOG (AVG VALUE) 

INDEPENDENT = END_I NTERV AL 
CURVE = Double logarithmic 

DEPENDENT = - IOG (AVG VALUE) 

INDEPENDENT = LOG ( E"ND_I NTERV AL) 



End Choice 



TABLE 22 

Process 4.3. 1.4 Basis Paths 



Complexity Metric: 5 



4. ami 

5. a jkl 



1 

2 

3 

4 
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************** ********** ********************************** 
4.3. 1.3 CALCULATE REGRESSION 



Inputs: DEPENDENT Source: Process 4.3. 1.1 

EATA POINTS Process 4.3. 1.1 

INDEPENDENT Process 4.3. 1.1 

LAST OBSERVED INTERVAL Process 4.3. 1.1 



Outputs: REGRESS ANALYSIS 
REGRESS~ANALYSIS 
REGRESS - ANA I YSIS 
REGRESS - A NA I YS IS 
REGRESS - ANALYSIS 



Destination: Process 4.3.2 
Process 4.3.3 
Process 4. 3. 4 
Process 4.3.5 
Process 4.3.6 



A. 

B. 

C. 

D. 

E. 

F. 

G. 

H. 

I. 

J. 

K. 

L. 

M. 

N. 

O. 

P. 

Q. 

R. 

S. 

T. 

U. 

V. 

w. 

X. 

Y. 



R 



= A + B * Z 
to LAST 'OBSERVED INTERVAL 
DEPENDENT 
(DEPENDENT ** 2) 
INDEPENDENT 
(INDEPENDENT ** 2) 
(DEPENDENT * INDEPENDENT) 



Define Function 
For I = 1 
P = P 

g: 8 

S = S 

u = u 

End For. 

SI = DATA POINTS * S - 
M2 = R / DATA POINTS 
B = (DATA POITTTS * U - P * R) 

A = jP - B * R) / DATA POINTS 
V = E * SQR (SI / (DATE POINTS 
For I = 1 to DATA POINTS 

N (I) = Fn R (INDEPENDENT) 
Ojl) = DEPENDENT - N (I) 

For. 



R ** 2 



/ SI 



Q - P 



** 



2) ) 



1 to 
01 + 



End 

For I = 

01 = 

End For. 

02 = 01 / 

03 = SQR 
B 1 = 

VARIA 
Forecast CURVE 



DATA 

0 ( 1 ) 



POINTS 

** 2 



(DATA E Cl NTS - 2) 

( 02 ) - 



(SQR ' (DATA 
TE = 0.688 



_PCI NTS) * 03) / SQR (SI) 
for a 50% confidence interval 
with highest correlation factor => V 



TABLE 23 

Process 4.3. 1.3 Basis Paths 



Complexity Metric: 4 

1. athi jklmngrtu vwxy 

2. atcdefghi jklmngrtuvwxy 

3. ahhi jkxmnop gr tuvwxy 

4. alhi jklmngrstuvwxy 
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************************************************************ 
4.3.2 PEARL CURVE FORECAST 



Inputs: VARIATE 

IDENTIFIER 
REGRESS ANALYSIS 
FACTOR VIEW 
MODEL_VlEW 

Outputs: EXPANDED MODEL VIEW 
EXPAN DED — FACTOR VIEW 
EXPANDED - FA CTCR - VI EW 



Source: Process 4.3.1 
Process 4. 3. 1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 

Destination: Manager 
Manager 
Process 4.3.1 



A. 

B. 

C. 



D. 

E. 

F. 

G. 

H. 

I. 



M. 

N. 

O . 

P. 

Q. 

R. 



T. 

0 . 



Define 

Define 

Define 



Function 

Function 

Function 



A + B * 
LIMIT / 
03 * SQR 



Zj 

j! 

NT: 



Print 

Print 

Print 

Print 



+ EXP ( Z) ) 

+ 1 / 

(DATA POINTS + (DATA POINTS 
* (Z~- M2) ** 2) / SI ) ) 

’ A = • ; EXP (A) 

' B = ' B 

’Correlation Coefficient =' 

'Standard Error of B =';B1 

INTERVAL = 1 

While INTERVAL <= LAST OBSERVED INTERVAL 

ESTIMATE = Function - P ( Function R( END INTERVAL) ) 
UPPER = ESTIMATE + ( VARIATE 

* Function F( END INTERVAL) 

LCWER = ESTIMATE - ( VARIETE 

* Function F( END INTERVAL) 

INTERVAL = INTERVAL + 1 - 

End While. 

INTERVAL = LAST OBSERVED INTERVAL + 1 

While INTERVAL ?= LAST INTERVAL NUMBER 

ESTIMATE = Function - P ( Function R( END INTERVAL) ) ) 
UFPER = ESTIMATE + t VARIATE 

* Function F( END INTERVAL) ) 

LOWER = ESTIMATE - ( VARIITE 

* Function F( END INTERVAL) ) 

INTERVAL = INTERVAL + 1 - 

End While. 



CORRELATION 



) 



) 



TABLE 24 

Process 4.3.2 Basis Paths 

Complexity Metric: 3 

1 . alcdefghinopu 

2. abcdefghi jklmncpu 

3. atcdef ghinopgrst u 
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****$******************************************************* 
4.3.3 GCMPERTZ CURVE FORECAST 



Inputs: VARIATE 

IDENTIFIER 
REGRESS ANALYSIS 
FACTOR VIEW 
MODEL_VlEW 

Outputs: EXPANDED MODEL VIEW 
EXPANDED - FACTOR VIEW 
EXPAN DED - FACTCR - VIEW 



Source: Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Proce ss 4.3.1 

Destination: Manager 
Manager 
Process 4.3.1 



= A + B * Z 
= LIMIT * EXP {-EXP ( Z) ) 
= 03 * SQR (1 + 1 / 



D. Print 'B = • ; EXP (A) 

E. Print ' K = ' :-B 

F. Print 'Correia ticn Coefficient ='; CORR ELATION 

G. Print 'Standard Error of K =';B1 

H. INTERVAL = 1 

I. While INTERVAL <= LAST OBSERVED INTERVAL 

J. ESTIMATE = Function - G ( Function R( END INTERVAL) ) ) 

K. UPPER = ESTIMATE + ( VARIATE 

* Function F( END INTERVAL) ) 

I. LCWER = ESTIMATE - ( VARIlTE 

* Function F( END INTERVAL) ) 

M. INTERVAL = INTERVAL ♦ 1 ~ 

N. End While. 

C. INTERVAL = LAST OBSERVED INTERVAL + 1 

P. While INTERVAL ?= LAST INTERVAL NUMBER 

Q. ESTIMATE = Function~G ( Function R{ END INTERVAL) ) ) 

R. UPPER = ESTIMATE + ( VARIATE 

* Function F( END INTERVAL) ) 

S. LOWER = ESTIMATE - ( VARIlTE 

* Function F( END INTERVAL) ) 

T. INTERVAL = INTERVAL ♦ 1 - 

U. £nd While. 



(DATA POINTS + (DATA POINTS 
* (Z - - M2) ** 2) / SI) ) 



A. Define Function R 

B. Define Function G 

C. Define Function F 



h\ 

Z 



— 

TABLE 25 

Process 4-3.3 Basis Paths 

Complexity Metric: 3 

1 . atcdefghinopu 

2. atcdefghi jklmnopu 

3. atcdefghinopgrstu 
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*********************************************** ******** ***** 



4.3.4 LINEAR CURVE FORECAST 

Inputs: VARIATE 

IDENTIFIER 
REGRESS ANALYSIS 
FACTOR VIEW 
MODEL_VlEW 

Outputs: EXPANDED MODEL VIEW 
EXP AND ED"* FACTOF VIEW 
EXPANDED - FA CTCR“VIEW 



Source: Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 

Destination: Manager 
Manager 
Process 4.3.1 



A. Define Function R (Z) = A + B * Z 

B. Define Function F Z) = 03 * SQR ( 1 + 1 / 

(DATA POINTS + (DATA POINTS 
* (Z - - M2) ** 2) / SI) ) 

C. Print 'Intercept = ';A 

D. Print 'Slope = ' ;E 

E. Print 'Correlation Coefficient = ' ;CORRELATION 

F. Print 'Standard Error of Slope =';B1 

G. INTERVAL = 1 

H. WHILE INTERVAL <= LAST OBSERVED INTERVAL 

I. ESTIMATE = Function“R( END INTERVAL) ) 

J. UPPER = ESTIMATE + ( VARIATE 

* Function F( END INTERVAL) ) 

K. LOWER = ESTIMATE - ( VARIlTE 

* Function F( END INTERVAL) ) 

1. INTERVAL = INTERVAL + 1 - 

M. End While. 

N. INTERVAL = LAST CESERVED INTERVAL + 1 

O. While interval LAST INTERVAL NUMBER 

P. ESTIMATE = Function - R ( END INTERVAL) ) 

Q. UPPER = ESTIMATE + 4 VARIATE 

* Function F( END INTERVAL) ) 

R. LOWER = ESTIMATE - ]f VARIlTE 

* Function F( END INTERVAL) ) 

S. INTERVAL = INTERVAL + 1 - 

T. End While. 



TABLE 26 

Process 4.3.4 Basis Paths 

Complexity Metric: 3 

1. afccdefghmnot 

2. atcdefghi jklmnct 

3. alcdefghmnopqrst 
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$*******$****$*$**££*$**£$£££****££*$*££***;$:£ *# ***$$*$*$*$** 
4.3.5 ICG CURVE FORECAST 



Inputs: VARIATE 

IDENTIFIER 
REGRESS ANALYSIS 
FACTOR VIEW 
MODEL VIEW 



Source: Process 4.3.1 
Process 4.3.1 
Process 4. 3. 1 
Process 4.3.1 
Process 4.3.1 



Outputs: EXPANDED MODEL VIEW Destination: Manager 
EXPANDED - FACTOR VIEW Manager 

EXPANDED” FACTOR - VIEW Process 4.3.1 



A. Define Function R (Z) = A + 3 * Z 

B. Define Function F (Z) = 03 * SQRfl + 1 / 

(DATA POINTS + (DATA POINTS 
* (Z - - M2) ** 2) / SI) ) 

C. Print 'Constant Term = ';EX?(A) 

D. Print 'Growth Rate = ' : 3 

E. Print 'Correlation Coefficient ='; CORE ELATION 

F. Print 'Standard Error of Growth Rate =';B1 

G. INTERVAL = 1 

H. While INTERVAL <= LAST OBSERVED INTERVAL 

I. ESTIMATE = EXP ( Function R( END INTERVAL) ) ) 

J. UPPER = ESTIMATE + ( VARIATE 

* Function F( END INTERVAL) ) 

K. LCWER = ESTIMATE - ( VARIlTE 

* Function F( END INTERVAL) ) 

INTERVAL = INTERVAL + 1 - 

. End While. 

INTERVAL = LAST OBSERVED INTERVAL + 1 
While INTERVAL LAST INTERVAL NUMBER 

ESTIMATE = EXP ( Function Ri( END INTERVAL) ) ) 

UFPER = ESTIMATE + ( VARIATE 

* Function F ( END INTERVAL) ) 

LCWER = ESTIMATE - ( VARIlTE 

* Function F( END INTERVAL) ) 

INTERVAL = INTERVAL + 1 - 

. End While. 



TABLE 27 

Process 4.3.5 Basis Paths 

Complexity Metric: 3 

1. atcdefghmnot 

2. abcdefghi jklmnct 

3. atcdefghmnopqrst 
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************************************************************ 
4.3.6 DOUBLE LOG CURVE FORECAST 



Inputs: VARIATE 

IDENTIFIER 
REGRESS ANALYSIS 
FACTOR VIEW 
M0DEL_VIEW 

Outputs: EXPANDED MODEL VIEW 
EXPANDED - FACTOR VIEW 
EXPAN DED - FA CTCR - VIEW 



Source: Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 
Process 4.3.1 

Destination: Manager 
Manager 
Process 4.3.1 



A. Define Function R (Z) = A + B * Z 

B. Define Function F (Zj = 03 * SQR{1 + 1 / 

{DATA POINTS + (DATA POINTS 
* (Z - - M2) ** 2) / 31) ) 

C. Print ’Constant = ';EXP(A) 

D. Print ’Power = ' ;E 

E. Print ’Correlation Coefficient =' ;C0RRELATI0N 

F. Print ’Standard Error of Power =';B1 

G. INTERVAL = 1 

H. While INTERVAL <= LAST OBSERVED INTERVAL 

I. ESTIMATE = EXP ( Function R( I0G ( END INTERVAL) ) ) ) 

J. UPPER = ESTIMATE + ( VARIATE 

* Function F( END INTERVAL) ) 

K. LOWER = ESTIMATE - ( VARI7STE 

* Function F( END INTERVAL) ) 

. INTERVAL = INTERVAL + 1 - 

. End While. 

INTERVAL = LAST CESERVED INTERVAL + 1 
While INTERVAL LAST INTERVAL NUMBER 

ESTIMATE = EXP ( Function R( L0G( END INTERVAL) ) ) ) 
. UPPER = ESTIMATE + ( VARIATE 

* Function F( END INTERVAL) ) 

LOWER = ESTIMATE - ( VAEIITE 

* Function F( END INTERVAL) ) 

INTERVAL = INTERVAL + 1 - 

End While. 



TABLE 28 

Process 4.3.6 Basis Paths 

Complexity Metric: 3 

1. ahcdefghmnot 

2. ahcdefghi jk lmcct 

3. atcdefghmnopqrst 
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$***:£************££$$$*$*£$$££****:**********************$*** 
4.4.1 MONTE CARLO 



Inputs: FIRM SELECT Source: Process 4.1 

EXPANDED FACTOR VIEW Process 4.3 

MODEL VIEW “ Process 4.1 

MODEL - S TRUCT UR E Process 4.1 

MCDEL - SCORE Process 4.4.2 

Outputs: MONTECARLO FORECAST Destination: Manager 

MODEL STRUCTURE Process 4.4.2 

AVG VlLUE Process 4.4.2 



A. For each FACTOR IE in MODEL STRUCTURE 

E. Do CUR VE_FUNCTIO N 

C. End For 

D. INTERVAL NUMBER = 1 

E. While INTERVAL NUMBER <= LAST OBSERVED INTERVAL 

F. Do CALCULATE MODEL SCORE “ 

G. AVG VALUE = ESTIMATE ( FACTOR ID) 

H. Do CALCULATE MODEL SCORE 

I. ESTIMATE (MODEL ID) = MODEL SCORE 

J. INTERVAL NUMBER = INTERVAL~NUMBER + 1 

K. Print using OESERVED DATA FORMAT 

L. End While. 

M. While INTERVAL NUMBER <= LAST INTERVAL NUMBER 

N. AVG VALUE = - ESTIMATE ( FACTOR ID) 

O. Do CALCULATE MCDEL SCORE 

P. ESTIMATE fMODEl ID) = MCDEL SCORE 

Q. AVG VALUE = UPFERfFACTOR ID) 

R. Do CALCULATE MODEL SCORE - 

S. UPPER (MODEL IE) = MODEL SCORE 

T. AVG VALUE = - LCWER (FACTOR ID) 

U. Do CALCULATE MODEL SCORE - 

V. LOWER (MODEL IE) = MODEL SCORE 

W. Print u sing - ESTIMATED DITA FORMAT 

X. COUNT =1 - 

Y. While COUNT <= ITERATIONS 

Z. For each FACTOR ID in MODEL STRUCTURE 

A’. AVG VALUE = - { (UPPER (FACTOR ID) 

- LOWER (FACTOR ID)) 

* RANDOM NUMBER) + LOWER (FACTOR ID) 

E 1 . End For. 

C'. Do CALCULATE MODEL SCORE 

D«. FREQUENCY (INTERVAL NUMBER , COUNT) = MODEL SCORE 

E* . COUNT = COUNT + 1 ~ 

F’. End While. 

G'. INTERVAL_NUMBEE = INT ERVAL_NU MBER + 1 

H 1 . Print Frequency Distribution 

I*. End While. 
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TABLE 29 

Process 4.4.1 Basis Paths 



Complexity Metric: 6 

1. acdelmi' 

2. afcdelmi' 

3. acdefghi jklmi ’ 

4. acdelmnopgr stuvwxyf ' g ' h 1 i 1 

5. acdelmnopgrstuvwxyzb’c' d'e'f'g'h'i' 

6 . acdelmnopgrstuvwxyza 'b'c’d’e'f'g'h'i' 



****^*************************************** *************** 



4.4.2 CALCULATE MODEI_SCORE 

Inputs: MODEL STRUCTURE 
AVG_VILUE 

Outputs: MODEL_SCORE 



Source: Process 4.4.1 
Process 4.4.1 

Destination: Process 4.4.1 



A. For Each GROUP 

E. If GROUP LEVEL = 1 

C. For each SUE_GROUP 

D. Sum the value of the AVG VALUES multiplied by 

the I ACTOR WEIGHTS for each FACTOR ID 

E. Multiply this sum by the SUB GROUP WEIGHT 

F. Remember this as the S UB_GROTJP_VALUE 

G. End For 

H. Multiply the SUB GROUP VALUES together 

I. Multiply the SU B - GROUP - VALUE by the 

GROUP WEIGHT - 

J. Remember this as the GROUP VALUE 

K. End If. 

I. End For. 

M. If there are 2 groups with a GROUP LEVEL = 1 then 

N. DIVIDE THE GROUP VALUE of the GROUP which has a 

GROUP TYPE = -,, Desirable" by the GROUP VALUE 
of the GROUP which has GROOP TYPE egual to 
"Undesira lie" 

O. Remember this number as MODEL SCORE 

P. End If 

Q. For each GROUP 

E. If GROUP LEVEL = 0 

S. GROUP - VALU Z = AVG VALUE * GROUP WEIGHT 

T. Multiply the GROUP VALUE times the MODEL_SCORE 

U. Remember this result as the MODEL SCORE 

V. End If. 

W. End For. 
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TABLE 30 

Process 4.4.2 Basis Paths 



Cctrplexity Metric: 7 

1. almpgv 

2. atklmpgw 

3. atcqhijklmpqw 

4. aicaefghi jklmpgv 

5. almnopgw 

6. almpqrvw 

7. almpgrstuvw 



5.1 CROSS IMPACT 

Inputs: FACTOR ID Source: Process 2.0 

IMPACT - F ACTO RS FACTOR File 

FACTOR - IMPACTS FACTOR File 

Outputs: CROSS IMPACT MATRIX Destination: Manager 

CROSS - IMP ACT - MATRIX Process 5.2 



A. Identify the FACTOR ID to observe 

E. Get list of IMPACT TACTORs 

C. N 1 = Number of IMPACT FACTORS 

D. For OBJECT = FIRST'LAST of set of IMPACT FACTORS 

E. Get list of I M F ACT FACTORS for each OBJECT 

F. For IMPACT = FIBST T LAST of set of IMPACT FACTORS 

G. If the IMPACT FACTOR is not listed in - the WORK 

File as an IMPACT_FACTOR on the OBJECT 
then 

H. CROSS IMPACT MATRIX ( OBJECT, IMPACT ) = 0 

Else — — ' 

I. CROSS IMPACT MATRIX ( OB J ECT, IM PACT ) = 

FACTOR IHPACT 

J. End If 

K. End For. 

I. IMPACT = OUTSIDE WORLD 

M. CROSS IMPACT MATBIX ( OBJECT, IMPACT ) = WORLD IMPACT 

N. End For. 
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TABLE 31 

Process 5. 1 Basis Paths 



Complexity Metric; 4 

1 . atcdn 

2. atcdefklmn 

3. alcdefgi jklran 

4. atcdefgh jklmn 






5.2 CALCULATE IMPACT 

Inputs: CROSS IMPACT MATRIX 
INITI£L_VALUE 

Outputs: RELATIVE TIME 
VALUE 



Source: Process 5.1 
Manager 

Destination: Manager 
Manager 



A. 

B. 

C. 

D. 

E. 
E. 

G. 

H. 

T 
_L • 

J. 



K. 



L. 

M. 

N. 



0 . 

P. 



• 

T. 

U. 

V. 



RELATIVE TIME = 0 

For CBJECT= FI RST ’LAST of set of IMPACT FACTORS Z 
OUTSIDE WORLD 
Do CALCULATE INITIAL VALUE 
VALUE (OBJECT) = INITTAL_V ALUE 
End For 

TIME INTERVAL = 0.001 

For RELATIVE TIME= 1 to 1000 

For IMPACT = FIRST'LAST of set of IMPACT FACTORS 
NEGATIVE (IMPACT) = DESIRABLE (IMP ACT) = 0 



For 



OBJECT= 

OUTSIDE 



FIRST'LAST 
WORLD 




* 

DESIR 



of set of IMPACT FACTORS Z 



nr AC T.O EJECT) ) ) 
OBJECT) ) 



End For. 



VA1UETOB JECTJ* 

ABIE (IMPACT) = DESIRABLE (IMPACT) 

+ ( (AES (CROSS IMPACT MATRIX (IMPACT .OBJECT) ) ) 
* CROSS IMPACT MATRIX (IMPACT, OBJECT) ) 

' V ALUE"(OBJECTF 



E (IMPACT) = (1 + TIME INTERVAL * (0.5) 

* NEGATIVE (IMPACT) ) / 

(i + time Interval * (0.5) 

* DESIRABLE (IMPACT) ) 

End For. 

For IMPACT = FIRST'LAST of set of IMPACT FACTORS 
VALUE (IMPACT) = VALUE (IMPACT) ** E (IMPACT) 

If VALUE (IMFACT) <= 1.0 ** (-70) then 

VALUE (IMEACT) = 0 
End If. 

End For. 

End For 
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TABLE 32 

Process 5. 2 Basis Paths 



Coirplexity Metric: 7 

1 . atef gv 

2. afccdefgv 

3. atefghopuv 

4. atef ghi gmnopuv 

5. atefghigklmnopuv 

6. ategni jmnopgrstuv 

7. ateghig mnopgr tuv 
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*********************************************************** 
6 MODEL CHANGE 



Inputs: INITIAL VALUE 
FACTOR VIEW 

model Structure 

CRO SS“I M PACT MATRIX 
FIRM SELECT “ 

GROUP WEIGHT 
SUB GROUP WEIGHT 
FACTOR WEIGH 1 
FACTOR~LIMIT 
MODEL ID 



Source: Process 5 
Process 4 
Process 4 
Process 5 
Process 2 
Manager 
Manager 
Manager 
Manager 
Manager 



Outputs: MODEL STRUCTURE 
MODEL~STRUCTURE 

FACTOR VIEW 

CROSS IMPACT MATRIX 

INITIAL VALUI 



Destination: Process 4 

MODEL STRUCTURE 
File 

Process 4 
Process 5 
Process 5 



Get FIRM SELECT 

If IDENTIFIER is a MODEL ID and CHANGE = "Model" then 
Change one of the following variables 
{GROUP WEIGHT} 

'SUB GROUP WEIGHT} 

{FACTOR WEIGHT} 

End If 

If CHANGE = "Factor" then 
For each FACTOR ID 

Change FACTCE_LIMIT if desired 
End For. 

End If 

If CHANGE = "Selection" then 

Change one of the following variables 
CHOICE 
WINDOW 
INTERVAL 
End Change. 

End If. 
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TABLE 33 

Process 6 Basis Paths 



Coitflexity Metric: 5 

1. atghlms 

2. atcdefghlms 

3. atghiiKlms 

4. atghiRlms 

5. ahghlninopgrs 



APPENDIX C 
DATA DICTIONAEX 

A. DATA FLOW COMPOSITIONS 



EARE_ FACTOR_VIEW 

EAR E_ MOD EL_ VIEW 

CROSS_IMPACT_MATRIX = 
ELEMENT_ENTRY 

EXPANDED FACTOR VIEW = 



FACTOR ID 
(FACTOR LIMIT) 

WINDOW “ 

INTERVAL 
{INTERVAL NUMBER 
BEGIN INTERVAL 
END_ITITERV AL} 

MODEL ID 
{MODEX LIMIT) 

WINDOW - 

INTERVAL 

{INTERVAL NUMBER 
BEGIN INTERVAL 
END_INTERVAL} 

FACTOR ID 
{IMPACT FACTOR 
FACTOR'IMPACT] 

DATE OF OBSERVATION 
{ELEMENT ANALYSIS 
ELEMENT - SOURCE 
DATE OF - ENTRY 
ELE ME NT^ VALUE} 

FACTOR ID 
(FACTOR LIMIT) 

WINDOW - 
INTERVAL 

LAST OBSERVED INTERVAL 
LAST - INTERV AL — NUMB ER 
{INTERVAL NUMBER 
BEGIN INTERVAL 
END ITITERV AL 
A VG — VALUE 
(ESTIMATE 
UPPER 
LOWER) 

OBSERVED} 
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EXPANDED MODEL VIEW = MODEL ID 



EACTOE 


(MODEL LIMIT) 

WINDOW" 

INTERVAL 

LAST OESERVED INTERVAL 
LA ST~I NTERV A L"NUMB ER 
{INTERVAL NUMBER 
BEGIN INTERVAL 
END INTERVAL 
MODEL SCORE 
(ESTIMATE 
UPPER 
LOWER) 

OBSERVE} 

= FACTOR ID 
FACTOF"TYPE 
CHARACTERISTIC 
(UNITS ♦ FACTOR LIMIT) 
[IMPACT FACTOR " 

FACTO R"IMPACT} 

OUTS IDE" WORLD 
{ELE ME NT_ ENTRY} 


FAC TOE_ VIE W 


= FACTOR ID 

(FACTOR LIMIT) 

WINDOW " 

INTERVAL 

LAST OBSERVED INTERVAL 
LAST"I NTERV AL"NUMBER 
{INTERVAL NUMBER 
BEGIN INTERVAL 
END INTERVAL 
AVG"VALUE 
OBSERVED} 


FIRM_ SELECT 


= IDENTIFIER 
CHOICE 
VALIDATION 
WINDOW 
INTERVAL 
(ITERATIONS) 


IDENTIFIER 


= [ MODEL_ID j FACTOR_I D ] 
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MODEL STRUCTURE 



MODEL VIEW 



REGRESS ANALYSIS 



SUB GROUP 



USER SELECT 



WINDOW 



MODEL ID 
{GROUP ID 
GRO UP - LE VEL 
GROUP~W EIGHT 
{GROUP TYPE) 
{SUB_GPOUP} 

MODEL ID 
(MODEL LIMIT) 

WINDOW - 

INTERVAL 

LAST OBSERVED INTERVAL 
LAST - 1 NT ERV AL - NUMBER 
{INTERVAL NUMBER 
BEGIN INTERVAL 
END INTERVAL 
MODEL SCORE 
OBSERVE} 

IDENTIFIER 

CURVE 

VARIATE 

B 

A 

STANDARD ERROR 

CORRELATION 

03 



SUB GROUP ID 
SUB — GROUP — WEIGHT 
1 {FACTOR ID 

FACTOR - WEIGHT} 

IDENTIFIER 

CHOICE 

(WINDOW) 

/INTERVAL) 

/ITERATIONS) 

BEGIN PERIOD 
END PERIOD 
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B. DATA ELEMENT DESCBIPTIONS 



A 


= type is digits 7 

* Temporary variable in 
regression calculation * 


AVG_VALUE 


= type is digits 7 

* Average of all data elements in 
a defined interval * 

First defined in 4.0 


E 


= type is FLOAT 

* Temporary variable in 
regression calculation * 


EEGI N_I NTEEVAL 


= type is range 0..100_000 

* Julian date representation of 
the date of the beginning of an 
interval. Base year is 1900 * 


BEGI N_ EEEIOD 


= type is range 0..100_000 

* Julian date representation of 
the date of the beginning of 
a period. Base year is 1900 * 


CHA RACTEEISTIC 


= type is (Endogenous, Exogenous) 

* Identifies whether a FACTOR is 
within users control or not * 


CHOICE 


= type is (Forecast, Monte-Carlo, 
Cross- Matrix) 

* Identify whether to run a 
forecast model or the cross- 
impact simulation * 


CORREIAIICN 


= type is digits 7 range 0.0.. 1.0 
* This is the R ** 2 result of 
regression analysis * 
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CURVE 


= type is (Pearl, Gompertz, Linear, 
Log, Double-Log) 

* Selection of curve function to 
utilize * 


DATE_OE_ENTRY 


= type is range 0..100_000 

* Julian date ELEMENT_ ENTRY is 
placed in the data base * 


DATE_OF_CBSERV AT ION 


= type is range 0..100_000 

* Julian date ELEMENT_ENTR Y • s 
ELEMENT_VALUE is observed * 


EL EMENT_ ANALYSIS 


= type is (Historical, Estimate) 

* Indicator of whether data is 
Observed or a DSS generated 
Estimate * 


ELEMENT_SOURCE 


= type is STRING ( 1 . .30) 
* Source of data for 
ELEMENT_ENTRY * 


ELEM ENT_ VALUE 


= type is digits 7 

* Value of ELEMENT_ENTRY * 


END_INTERVAL 


= type is range 0..100_000 

* Julian date representation of 
the date of the ending of an 
interval. Base year is 1900 * 


END_PERICD 


= type is range 0..100_000 

* Julian date representation of 
the date of the ending cf 
a period. Base year is 1900 * 


ESTIMATE 


= type is digits 7 

* An ELE MENT_ VALUE generated by 
the DSS * 
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FACTCE_ID 


= type is STRING ( 1. . 21) 

* Unique name of a FACTOR in the 
format 'F. XXXXXXXXXX. TTTTTTTT ' . 
The 'F.' indicates it is a 
FACTOR_ID, the 'X' is for the 
name within a technology, the 
'T' is for the technology * 


FACTCE_I MPACT 


= type is STRING (1. 21) 

* The FACTOR_ID of a FACTOR which 
has an impact on the key 
FACTOR * 


FACTOR_LIMIT 


= type is digits 7 

* Highest value which an ELEMENT_ 
VALUE may ever be. Could be a 
null value if there is no 
limit * 


FACTCR_TYPE 


= type is (Subjective, Ob jective) 

* Indicator of whether a FACTOR 
is a subjective or objective 
value * 


FAC TO E_ WEIGHT 


= type is delta 0.1 range 0.C..1.0 
* a subjective weighting of a 
FACTORS impact in a model * 


GROUP_ID 


= type is STRING ( 1. .21) 

* Unique name of a GROUP in the 
format «G. XXXXXXXXXX . TTTTTTTT' . 
The ' G . ' indicates it is a 
GROU P_ID, the 'X' is for the 
name within a technology, the 
'T' is for the technology * 
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GRO UP_IEVEL 


= type is range 0..1 

* Indicator of which GROUPS act 
upon other GROUPS. Low numbers 
act on high numbers * 


GROUP_T YFE 


= type is (Desirable, Undesirable) 

* Indicator of whether a GROUP is 
a desirable value or an 
undesirable value * 


GROUP_WEIGHT 


= type is delta 0.1 range 0.0. .1.0 
* a subjective weighting of a 
GROUPS impact in a model * 


IMPACT, FACTOR 


= type is delta 0.1 range 0.0.. 1.0 
* Subjective value of the impact 
of one FACTOR upon another * 


INTERVAL 


= type is range 1..100_000 

* Length of each interval over 
which to average data values 
for forecasting as measured in 
days * 


INTER VAL_NUMBER 


= type is range 1..400 

* Number of intervals in the 
WINDOW defined by the user * 


ITERATIONS 


= type is range 1..500 

* Number of types to execute 
Monte Carlo simulation * 
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LAST_INTERVAL_NUM3ER = type is range 1..400 





* Last I NTERVAL_ NUMBER in WINDOW 
defined by the user * 


LA ST_CESER VED_ 


INTERVAL = type is range 1..400 

* Last interval which contains 
data which is Historical * 


LOWER 


= type is digits 7 

* The lower value of the 
confidence limit for an 
interval in regression 
analysis * 


MODEL_ ID 


= type is STRING ( 1. . 21) 

* Unique name of a 

MODEL_STRUCTURE in the 
format ’M. XXXXXXXXXX. TTTTTTTT’ . 
The 'M.* indicates it is a 
M0DEL_ID, the »X» is for the 
name within a technology, the 
* T* is for the technology * 


M2 


= type is digits 7 

* Temporary variable in 
regression calculation * 


OBSERVED 


= type is range 0..1000 

* Number of ELEM ENT_V ALUES in an 
INTERVAL * 


OUT S ID E_ WORLD 


= type is delta 0.1 range 0.0. .1.0 
* Subjective impact of world upon 
a FACTOR * 


03 


= type is digits 7 

* Temporary variable in 
regression calculation * 



104 



RELATIVE_TIME 


= type is range 0..1000 

* An counter of relative time 
periods in the Cross Impact 
Analysis * 


STANDS FD_ERROR 


= type is digits 7 

* The standard error of the 
estimate of the dependent 
variable in the regression 
analysis * 


SUB_GEOUP_ID 


= type is STRING ( 1. . 21) 

* Unique name of a SUB_GROUP in 
format «S. XXXXXXXXXX. TTTTTTTT’ 
The 'S.' indicates it is a 
S UB_GROUP_ID, the • X' is fcr 
name within a technology, the 
1 T' is for the technology * 


SU3_GR0UP_ WEIGHT 


= type is delta 0.1 range 0.0. .1.0 
* a subjective weighting cf a 
S UB_GROUPs impact in a model * 


SI 


= type is digits 7 

* Temporary variable in 
regression calculation * 


UNITS 


= type is STRING ( 1. . 20) 

* Units of measure for 
ELEMENT VALUES * 
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UPPER 


= type is digits 7 

* The upper value of the 
confidence limit for an 
interval in regression 
analysis * 


VALIDATION 


= type is (Valid, Not-Valid) 

* Indicator of whether a 

USER_SELECT is acceptable * 


VARIATE 


= type is delta 0.001 

range 0.000. . 1.000 
* Value to determine the 
confidence interval in 
analysis * 
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